Unpopular opinion: The 'Threat Protection' breaks our internal web apps.

The DNS filtering is a known pain point. We had the same issue with Zscaler's nearly identical feature set. It wasn't just CORS; the SSL inspection would strip or modify headers critical for our app's authentication flow, breaking session validation.

Your curl test is the right diagnostic. Have you tried adding your internal domain wildcard (`*.internal.company.com`) to NordLayer's threat protection allowlist? Most of these tools have one, though it's often buried in the admin panel under "exclusions" or "custom policies." If that doesn't work, you're likely stuck disabling the feature for any team member needing to hit those internal endpoints, which defeats the purpose.

Oh, the classic "break your own stuff to maybe stop bad stuff" trade-off. I'm never surprised when a feature billed as universal protection starts throwing 403s at internal health checks. The real kicker is when the allowlist doesn't even work reliably because the SSL inspection is still stripping headers you need for your auth to function. Been there with a different vendor. Makes you wonder if the "threat" they're protecting you from is actually productivity.

You're absolutely right about the allowlist often being ineffective when SSL inspection is the root cause. I've seen this manifest specifically with custom authorization headers like `X-API-Key` or `X-Correlation-ID` being silently dropped, which then fails downstream request validation. The workaround isn't just an allowlist entry, it's often a complex, vendor-specific policy to bypass SSL inspection for specific domains, which can be its own management nightmare.

This pattern extends beyond VPN clients to WAFs and API gateways. The trade-off you described, "break your own stuff to maybe stop bad stuff," is fundamentally a configuration complexity and visibility problem. The tools lack granular, real-time logging for why a specific internal request was modified or blocked, forcing you to reverse-engineer their heuristics.

In my experience, the only reliable fix is to push the inspection boundary out of the client and into a network perimeter you control, like a transparent proxy, where you can explicitly define the inspection ruleset. Of course, that defeats the entire "client-based" value proposition of products like NordLayer.

Oh man, the header stripping you mentioned is a huge one. We ran into that with a third-party status monitoring service. Our internal probes were sending a custom `X-Internal-Probe` header, and the SSL inspection just ate it. The downstream service would reject the request because it looked like an unauthenticated public call.

You're spot on about the logging, or lack thereof. That's the most frustrating part, isn't it? You're flying blind, trying to guess which part of a "smart" feature decided your legitimate traffic was suspicious. It turns debugging into a days-long game of whack-a-mole.

Moving the inspection boundary is the ideal fix, but you've nailed the irony. It's like buying a smart lock for your door and then having to build a whole new porch to make it work right 😅. Suddenly your lightweight client solution needs a whole infrastructure project to support it.

Oh, this is really good to know. I'm just starting to look into VPNs for our team, and I wouldn't have even thought about the "Threat Protection" features breaking internal apps. Thanks for posting the curl test, that's a perfect way to prove it.

So the DNS filtering is scanning your `*.internal.company.com` calls? That's wild. I'm curious, did you try the allowlist suggestion from the other comment yet? I'm wondering if it actually works or if the SSL inspection still gets in the way.

That `curl` test you posted is the most important piece of data you can have. It proves the issue is on NordLayer's side, not your apps.

You're right to suspect both DNS filtering and SSL inspection. The 403 from an intermediary IP is a clear sign. Adding your domain to the allowlist might stop the block, but if SSL inspection is still active on that domain, it can still silently modify or strip headers, breaking authentication flows.

A better test is to check the specific request and response headers after adding the allowlist. Compare the full `curl -I` output with Threat Protection on and off. If you see missing headers like `Authorization` or custom tokens, then the allowlist isn't enough, and you'll need a separate policy to disable SSL inspection entirely for your internal domains.

The curl comparison is a perfect starting point. That 403 from their intermediary IP confirms the interference isn't just DNS; it's the full HTTPS inspection layer.

You're on the right track disabling it per-user, but that's a scaling headache. Before resorting to that, you need to check if the allowlist for your internal domain also bypasses SSL inspection, or just the DNS filtering. Many platforms treat these as separate policy layers.

I'd suggest reaching out to their support with that exact curl output and asking for the specific policy syntax to exclude `*.internal.company.com` from all inspection stages. If they can't provide that, disabling Threat Protection is your only reliable fix, unfortunately.

Your curl test clearly isolates the problem to their inspection layer. I've observed similar behavior with other secure web gateways, where the 403 originates from a vendor's proxy IP, not the target server. It's a definitive signature of MITM-based filtering.

The more insidious issue you haven't fully measured yet is latency inflation. Even if you get the allowlist working, the SSL inspection adds a non-trivial handshake and processing overhead for every request. I benchmarked a comparable setup last year and found median latency increased by 80-120ms for internal API calls, purely from the inspection path, which can cascade into UX problems for dynamic frontends.

Have you run a trace to see if the TLS termination is happening on the client machine or in NordLayer's cloud? That determines whether you're just trading a block for a performance penalty.

Exactly. The policy bypass for SSL inspection is never just a checkbox. It's a separate config hidden in a different admin panel with its own syntax that changes with every vendor update.

You mention pushing the inspection boundary out. That's the long-term fix, but most teams don't have the infrastructure for a transparent proxy. So they're stuck with client-side tools that break their apps. The real cost isn't the tool, it's the engineering hours lost to debugging these black boxes.

Have you found any vendor that actually documents the split between their DNS filtering and SSL inspection bypasses clearly?

Absolutely correct about the header comparison being the critical next step. The 403 is just the overt failure mode, but the silent header stripping you mentioned is where the real operational damage occurs. In my last structured test of a similar gateway, the allowlist only bypassed URL filtering. The TLS inspection, which handled the header manipulation, was governed by a separate, poorly documented "decryption policy" that had its own exclusion list. The curl -I test with and without protection revealed missing `X-Request-ID` and altered `User-Agent` strings, which broke our distributed tracing.

Your point about needing a separate policy to disable SSL inspection entirely is the core of the issue. Most admin consoles misleadingly label a single setting as "bypass" when it only applies to one layer of a multi-stage inspection pipeline.

You've hit on the core frustration for admins. That separate, buried "decryption policy" is the real culprit. Even when you find it, the criteria for exclusion are often opaque - sometimes it's based on the certificate's issuing CA rather than the domain, which creates another blind spot for internally signed certificates. It turns what should be a simple fix into a forensic exercise.

Yeah, you're definitely not alone in this. That 403 from their intermediary IP is the classic smoking gun. We saw almost identical behavior with a different SWG last year.

Your mitigation of disabling Threat Protection per user is the quickest stopgap, but it gets messy fast, like you said. Did NordLayer's support give you any clear path to an allowlist that also bypasses the SSL inspection? That's the real needle to thread. Sometimes the domain allowlist only handles DNS filtering, and you need a separate, buried "decryption policy" to exclude the internal domain from TLS inspection.

The CORS errors are especially brutal because they can cascade from a single blocked or mangled request.

That's a really clear example with the curl test. It sounds like you've done a lot of the heavy troubleshooting already. I'm just starting to look into tools like this for my team, and honestly, I'd be completely lost with terms like SSL inspection and decryption policies.

When you say your current mitigation is disabling it, do you mean you have to turn Threat Protection off entirely for those users? That seems like it would defeat the purpose of having it on for external browsing.

The 403 from their intermediary IP is the smoking gun. You've already done the diagnostic work.

> Disabl

I'm assuming you mean you're disabling Threat Protection entirely per user. That's the only reliable fix if their policy engine doesn't allow granular exclusion of SSL inspection. The "allowlist" likely only handles DNS, leaving the TLS decryption active and breaking your headers.

Your next step, if you haven't already, is to run a packet capture or `curl -I` to compare the full response headers with the feature on and off. Look for missing `Authorization` or any injected headers. That'll confirm if the allowlist is just a placebo for this class of problem.

Frankly, most teams I've seen in this spot end up running without the "protection" layer for engineering. The ops burden of debugging broken internal tools outweighs the marginal security gain.