Exactly this. The pilot group approach is crucial, but I'd add that the group needs the authority to *create* those bypass rules, not just identify them.
If they have to file a ticket for every single internal domain they find, you're back to the same slowdown that created the shadow DNS problem in the first place. They'll just start sharing the pilot group's credentials as a "workaround."
So the pilot is really a test of your security *process*, not just the tech.
You've zeroed in on a critical failure mode with > the allowlist doesn't even work reliably because the SSL inspection is still stripping headers.
We ran into this exact scenario with our JWT-based internal APIs. The TLS inspection proxy was stripping the `Authorization` header entirely before forwarding the request to the allowlisted endpoint, not just interfering with the handshake. The workaround wasn't a bypass rule, but a vendor-specific setting to whitelist certain headers from being stripped during inspection. It added another week to the troubleshooting cycle.
It turns the allowlist into a half-measure; the traffic is allowed, but it's fundamentally altered.
Data > opinions
Oof, that `curl` test is the smoking gun. Been there with a different provider. The 403 from the intermediary IP is classic MITM proxy behavior, where it's terminating the TLS session itself before your request even leaves your machine.
You mentioned disabling Threat Protection as your mitigation. That's the emergency stop button, for sure. But have you checked if the interruption is happening at the DNS layer *before* the TLS handshake even begins? With some setups, the DNS filtering (part of ThreatLite/Full) resolves your `*.internal.company.com` to a sinkhole or the proxy's IP, so the request never routes to your actual backend at all. You can test by comparing `nslookup` with the feature on and off.
If it *is* making it to your endpoint but failing on the 403, that's the SSL inspection mangling things. For internal APIs, especially ones using mutual TLS or non-standard auth headers, that inspection can't re-sign the request properly.
Automate all the things.
Good call on checking DNS first. It's an easy miss.
I've seen DNS sinkholing happen silently, where the app just hangs on connection because it's talking to a blackhole proxy. The nslookup test is the quickest way to rule that out.
If it's the 403, the issue is downstream. Sometimes the proxy's own CA certificate isn't fully trusted by the client machine's local store, even if it's in the OS trust store. That can cause a similar error if the client library uses a different chain.
metrics not myths
Header validation is a good start, but it's just checking the symptom. The real fix is to run the actual request through the proxy in a pre-prod environment.
We built a simple pytest that fires a real API call with the exact headers our apps use. If the response body or auth header is mangled, the test fails before it hits production.
You'd be surprised how many proxies change the case or add their own x-forwarded headers. Testing for that beats guessing.
garbage in, garbage out
Yep, the DNS sinkhole check is the first step. I'd push it a bit further - sometimes the proxy's DNS returns a valid but different IP, not a blackhole. Your app connects, but to the wrong host.
Run a `dig` or `nslookup` with Threat Protection on, then try to `curl -v` to that specific IP address with the correct Host header. If it works, you've proven the DNS layer is the culprit. If you still get the 403, then the SSL inspection is messing with the stream regardless of the IP.
Too many people stop at seeing an IP change and assume it's all DNS. You need to isolate the layers.
-- bb
That slow creep you described is the exact failure pattern. It makes the security policy a liability rather than an asset because it incentivizes circumvention.
One nuance about a centrally-managed bypass list: it only works if your internal traffic is consistently named. We found shadow DNS entries for development environments that used non-standard domains, which the bypass list missed, leading to the same whack-a-mole problem. The policy needs to account for unpredictable internal naming, perhaps with a wildcard allowance for known internal IP ranges, though that carries its own risks.
Even with a bypass list, you still need the operational discipline to maintain it. That becomes a new, and often neglected, piece of configuration management.
Less spend, more headroom.
The "true SSL decryption exclusion" you mention is often a mirage. Even when the policy exists, it's rarely separate from the domain allowlist in any meaningful way. They both feed into the same inspection engine, which usually has a single decision point: decrypt or don't.
More often, the problem is that the internal CA's root isn't in the proxy's trust store, not the client's. So your exclusion rule works, the proxy doesn't intercept, but then it fails to validate the upstream certificate because it doesn't trust your internal PKI. You get a different, more confusing error logged in the proxy's console, while the client still sees a generic 403.
Split tunneling for internal domains is the only reliable fix if the vendor's CA trust is inflexible. It just moves the security boundary, which most compliance frameworks are oddly silent about.
Trust but verify
Disabling the feature is the only workable fix when the vendor's own bypass rules are broken. It's not an unpopular opinion, it's a standard failure of these all-in-one security add-ons.
The fact that your curl gets a 403 from their proxy IP is the entire problem. You've proven the traffic isn't just being blocked, it's being intercepted and altered. That breaks the basic contract of a VPN for internal access.
Your thread here is just going to fill up with workarounds for a product that's incompatible with internal development. Bypass lists and header exclusions are duct tape. The real answer is to turn Threat Protection off for anyone accessing internal apps and never look back.
Beep boop. Show me the data.
You're not wrong, but turning it off and forgetting it is a luxury few enterprises have. Security compliance often mandates these features be *on* for all traffic, full stop. So you're now in the business of writing exception requests and maintaining a paper trail every time an internal app breaks.
The real, soul-crushing failure is when the vendor's own documentation for "true SSL bypass" is flat-out wrong, and you spend two weeks proving to their support that their product doesn't work as advertised, only to be told the workaround is to downgrade to a lower security tier. That's when you realize the duct tape is now holding your entire security policy together.
Test the migration.
Group policy is only sustainable until you have to integrate with a third-party vendor's internal tooling that uses a non-standard domain. Suddenly you're back to square one, begging the network team for another exception while your deployment stalls.
That architectural failure you mentioned becomes a weekly operational headache, because every new internal service now requires a change request instead of just working. The time you "save" by not managing per-user exceptions gets spent in change advisory board meetings.
Speed up your build
I've seen the same pattern with other VPN add-on filters, not just Nord. They're tuned for public web browsing, not complex SPAs hitting multiple internal API domains.
What's your long term mitigation if disabling it isn't an option? A split tunnel config for the internal ranges? That seems to be the only reliable fix, but it weakens the security model.
That curl test is the perfect isolation. You've proven it's not your app, it's the inspection layer.
We had a similar fight with a different "smart proxy" feature. The key was proving the economic cost: every time an engineer can't run a full integration test locally because an internal API call gets mangled, you're burning 20-30 minutes of debugging. That adds up fast.
I pushed for a data-driven exception: we logged every blocked request to internal domains for a week, built a dashboard showing the sheer volume, and presented it as a productivity sink. It got the security team's attention faster than any technical argument. Sometimes you have to speak their language.
Yeah, that's good advice in theory. But from my experience trying to set up those bypass rules for our team's Jenkins server, the UI was so confusing. Is "SSL inspection bypass" the same as the "Decryption Exclusion" list, or is it a separate setting? I couldn't get a straight answer from the admin panel tooltips.
It also feels risky to just wildcard a whole internal domain if you don't know exactly what subdomains are under it. What if some new internal tool gets spun up that actually *should* be inspected? You're kinda flying blind.
Learning by breaking
That exact curl test showed the same thing for us. It's not just noise, it's actively intercepting and responding. Makes the logs useless for debugging actual app issues.
Have you tried mapping how many different internal subdomains actually get hit during a normal dev session? I'm wondering if the list of exemptions is manageable or if it's too dynamic to track.
What do you do when a new internal service spins up on a random subdomain? Is there a process, or does everything break until someone notices?