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

That `curl` test is the crucial first step, but the deeper issue is understanding the two distinct layers you're up against. The 403 from the intermediary IP confirms SSL/TLS inspection is active, meaning the proxy is terminating your connection. However, the DNS-based filtering component can block requests before they even reach that inspection point.

Your next diagnostic step should be to run a DNS lookup from the affected machine with Threat Protection both on and off. If the lookup itself fails or returns a different IP (like a sinkhole), then the DNS filter is the initial blocker. If the DNS resolves correctly but the `curl` fails with the 403, then the SSL inspection proxy is the culprit. You need to configure separate exclusions for each function; a whitelist for DNS filtering won't automatically bypass inspection.

For internal domains, you typically need a bypass rule that tells the inspection proxy to act in TCP pass-through mode, leaving the TLS connection between your client and the internal server untouched. This preserves custom headers, certificate pinning, and mTLS. Check if NordLayer's policy interface has this as a distinct setting from the simple 'allow list'.

That's a really helpful breakdown of the two layers. I hadn't even considered the DNS lookup test to separate the block from the inspection failure. Makes sense.

So when you say a TCP pass-through bypass rule, does that usually mean the proxy is still *seeing* the traffic but just not decrypting it? I'm wondering if that still adds any latency compared to a full exclusion.

Six months in and you're still using the health check endpoint for diagnostics? That's setting the bar low. The `curl` test shows the symptom, not the cause.

You'll probably find the 403 is from the inspection proxy, not the DNS block list. The real question is what happens when you "disable Threat Protection at the user level" - does that turn off *all* filtering, or just the SSL inspection? Most vendors conflate the two, so your engineers end up with zero protection for all traffic, not just the internal domains.

Have you audited what else is getting through now that you've flipped the switch off?

You're right about the diagnostic bar being low, but the real operational cost is that all-or-nothing user-level toggle. Disabling the entire suite for engineers to fix one app creates a massive compliance blind spot that's rarely logged.

I've seen vendors where that single toggle also disables URL filtering and DNS security, not just SSL inspection. The engineer now has unfettered access, and the next audit flags a policy violation because the exception wasn't scoped. The fix creates a new security finding.

Have you checked your vendor's admin logs to see what categories of traffic are now flowing for that user group since the switch was flipped? That's usually where the surprise comes from.

Oh man, the vendor logs point is so true. We ran into this with Zscaler - the "temporary bypass" for a dev group turned off all URL filtering. The next week's report showed a bunch of visits to high-risk categories that had previously been blocked. Caused a whole security review meeting over "policy exceptions."

The real kicker? The logs didn't even tag it as a bypass exception, so it looked like intentional policy failure. Makes you wonder if the all-or-nothing toggle is a vendor design flaw or a feature to sell more granular controls.

Your curl test points straight at the SSL inspection proxy blocking it. That's the easier layer to bypass compared to DNS sinkholing.

But you cut off your mitigation list. If you're just disabling Threat Protection at the user level, check the admin logs. You've probably turned off URL filtering for all traffic, not just for your internal domains. Creates a compliance hole.

That curl output is your concrete evidence. It's not a CORS config issue in your app, it's the proxy terminating the connection.

> Disabl

I assume you were going to say "disable Threat Protection at the user level." That's a sledgehammer fix. As others pointed out, you're likely turning off all filtering, including web/dns security for *everything*, just to get your internal domains working.

You need to find the proper bypass rule, not the global toggle. Look for "SSL inspection bypass" or "decryption exclusion" in the NordLayer admin panel and add your `*.internal.company.com` pattern there. That should allow the traffic through without inspection, while keeping the rest of Threat Protection active for external sites.

Oh, the OAuth/webhook breakage is the absolute worst. We had a deployment pipeline that would *seem* to succeed, but the webhook from GitHub to our internal CI system would get a 403. The proxy's re-signing cert wasn't in our internal service's trust chain, so the payload never arrived. Took us a week to realize no new builds were triggering on merges.

For the fallback, we had to bake it into our internal DNS. We set up a CNAME like `*.internal-bypass.company.com` that points to the same internal IPs but isn't subject to the VPN's filtering policies. It's a hack, but when a new microservice spins up, devs can temporarily swap the hostname in their config to get unblocked while the proper whitelist ticket churns through IT. Not elegant, but it stops the bleeding.

Ah, the old "shadow DNS" workaround. Sure, it stops the bleeding, but you've just institutionalized a second, unofficial namespace that you now have to document and maintain forever. Classic.

The real joke is that this gets implemented because the "proper whitelist ticket churns through IT," which is really just admitting the security policy can't keep pace with actual work. So the solution is... a parallel, less-secure network path. What could go wrong?

Has anyone checked if your compliance tooling is also monitoring traffic to `*.internal-bypass.company.com`, or is that log file just for fun?

The "parallel, less-secure network path" is exactly what it is. And it's not just a logging gap. Once that CNAME exists, it inevitably ends up in configs, IaC templates, and service discovery. You now have a permanent, undocumented split-brain DNS.

The root cause isn't the team's bypass. It's that the security policy's change mechanism is a ticket with a multi-day SLA. Engineering velocity measured in minutes can't wait for that. So they build a workaround, and the workaround becomes the system.

The only fix is to automate the whitelist. If adding a domain to the SSL bypass list takes a PR and a 2-minute pipeline, the shadow namespace dies.

Great question about the VPN reconnect. In my experience with NordLayer, toggling Threat Protection off for a user profile does *not* require a reconnect, the change applies almost instantly to new connections. That's the good news for user experience.

The bad news is exactly what others have flagged - that toggle is a total on/off switch for the entire security suite, not just SSL inspection. So your non-tech team members would suddenly have no web filtering or DNS security at all. For a quick internal app fix, you're accidentally exposing them to everything else.

Have you looked into whether your VPN offers a decryption exclusion list? That's the real fix, letting you bypass just for specific internal domains.

Hi there, appreciate you sharing the concrete curl results, that's super helpful for diagnostics. It really does point directly to the SSL inspection as the culprit.

A lot of folks have already flagged the main risk with the full toggle, and I have to agree. Disabling Threat Protection at the user level isn't just fixing your internal apps, it's removing a security layer for everything else that person does. It's a very common oversight.

The path forward is almost certainly a decryption exclusion or SSL bypass rule for your internal domains. It's the proper way to let that specific traffic pass through untouched while keeping the protection active everywhere else. Have you had a chance to look for that in your NordLayer team management panel? It's often under the policy or threat protection settings. Setting an exception for `*.internal.company.com` should solve it without the compliance side effect.

Completely agree on the decryption exclusion being the proper path. The detail I'd add is to check how that rule is logged in the audit trail after you set it. Some systems log the creation of the bypass rule, but then subsequent connections that hit the rule just show as "allowed" without the crucial context of "allowed due to SSL bypass rule X." Without that, your monthly threat report could show a bunch of traffic to an internal domain that, to an untrained eye, just looks like it's passing through uninspected for no reason.

Have you seen that logging gap before? It makes the exception list harder to defend in an audit because the 'why' isn't attached to each event.

That's a really clear example with the curl test, thanks for sharing it.

I'm just starting to look into NordLayer for our team. Is this a common thing, needing to set up these bypass rules for internal tools? Our stack sounds similar, and I'd hate to roll it out only to break our dev environments right away.

Yes, it's common. Any VPN or security proxy that does TLS inspection will break internal apps unless you plan for it.

When you roll out, don't start with a blanket enable for the whole team. Pilot it with a technical group first. That gives you time to identify the internal domains that need bypass rules without crippling everyone's workflow on day one.

The key is having those decryption exclusions ready *before* the wider rollout.