Hey everyone 👋 I've been using NordLayer for about six months to secure our team's development environments, especially when accessing cloud resources. It's generally been solid, but we just hit a serious snag.
During our routine security penetration test, the red team flagged consistent DNS leaks on several of our developer workstations. The test was simple: they used sites like `dnsleaktest.com` and `ipleak.net` while connected to NordLayer. The results showed queries going to our local ISP's DNS servers instead of NordLayer's, which is a major privacy and security issue for us.
We contacted support immediately. Their response was... disappointing. They basically said to use the "default" settings and that "DNS leak protection is enabled by default." When we pressed with the specific test results, they just sent us a generic troubleshooting article about restarting the app and reinstalling. Not helpful for a systematic issue.
Has anyone else run into this? I'm wondering if it's a configuration problem on our end or a known limitation. Here’s a snippet of the simple Python script our pentesters used to verify the leak (it's just calling `nslookup`):
```python
import subprocess
import sys
def check_dns_servers():
try:
# This will show the DNS server responding
result = subprocess.run(['nslookup', 'example.com'], capture_output=True, text=True, timeout=5)
print(result.stdout)
except Exception as e:
print(f"Error: {e}", file=sys.stderr)
if __name__ == "__main__":
check_dns_servers()
```
Our current setup:
- NordLayer app (latest version) on macOS and Windows.
- Using the "Automatic" protocol selection.
- Split tunneling is **disabled** (all traffic goes through the VPN).
We need this fixed. A VPN that leaks DNS isn't fulfilling its core promise. I'm considering:
* Manually setting DNS to something like Cloudflare (1.1.1.1) in the OS, but that defeats the purpose of the VPN's own DNS.
* Looking into the CLI or config files for advanced settings, but documentation seems sparse.
Any deep-dive experiences or workarounds would be hugely appreciated. Did you have to switch to a different provider to solve this, or was there a specific NordLayer setting that finally worked?
Clean code is not an option, it's a sanity measure.
Yep, seen this happen with split tunneling configurations. If your devs have any local routes or service IP ranges excluded from the VPN tunnel, DNS requests for those endpoints might take the physical interface and leak. NordLayer's split tunneling can be a bit too permissive by default.
Check if you have any custom routes set. You could temporarily disable split tunneling entirely for the pentest to confirm it's the culprit. If you need it, you might have to enforce a custom DNS (like 1.1.1.1) at the host level as a workaround until they fix it.
That's a really good point about split tunneling. It hadn't occurred to me that excluding a local server IP could also let DNS slip out. I'm trying to learn about this stuff for my own team's setup.
Would forcing a custom DNS at the host level, like you mentioned, actually stop the leak if the VPN app itself is misrouting the query? Or would the app's request still bypass that setting?
You're right on the money about split tunneling being the likely vector. Your point about it being "too permissive by default" matches what I've observed in other business VPN clients during audits. They often prioritize connectivity over strict leak protection.
One nuance here is the distinction between system-level and application-level DNS. If a developer's machine has, say, a local Kubernetes cluster excluded via split tunnel, any application trying to resolve a service in that cluster will ask the OS for DNS. The OS, seeing the destination is in an excluded IP range, will often send the DNS query out the physical adapter using whatever DNS server is configured there (usually the ISP). The VPN's DNS server never even gets asked.
Forcing a custom DNS at the host level, like pointing to Cloudflare or Google DNS, would technically stop the ISP leak in that scenario, but it also partially defeats the purpose of the VPN's own DNS, which might have internal corporate resources. It's a band-aid that introduces a different trade-off.
Ugh, that support response is frustrating. Generic restart/reinstall advice for a security finding is totally inadequate. We've had similar flags during our SOC2 prep.
It's almost certainly not *just* your config. I've found these VPN services often have a blind spot: they handle DNS perfectly for full-tunnel traffic, but the moment you introduce any split tunneling for dev resources (like a local cloud emulator or a company intranet range), their "default" protection breaks. The app seems to just pass the DNS request to the OS, trusting it'll use the VPN's DNS, but the OS uses the physical adapter's DNS for the excluded IPs.
Could you share if you're using split tunneling? That's usually the smoking gun. If you are, their "enabled by default" claim is misleading at best.
Happy hacking!
That's a good question. Forcing a custom DNS at the host level should stop the leak to your ISP, because you're overriding the DNS server the OS uses for the physical adapter. But as others mentioned, the VPN app still won't see that query for the excluded IP range.
So you'd be stopping the leak, but you also wouldn't be using NordLayer's DNS at all for those requests, which might defeat part of the purpose. It's more of a containment tactic than a fix.
Oh, that's a great test script from your pentesters - real-world verification beats marketing claims any day.
It's definitely a known issue with many VPN clients, especially when split tunneling is active. Their support giving you the boilerplate "default protection" line is a red flag. A proper security vendor should have a documented behavior for this exact scenario.
For a quick fix, you could enforce DNS via a Group Policy or MDM script to override the adapter settings. But the real question is whether you should have to. If a security product leaks in a standard dev configuration, maybe it's not the right product.
git push and pray
That Python script snippet is the key detail. If your pentesters wrote a script that triggers `nslookup` for a hostname within a split-tunneled IP range, they've perfectly isolated the failure. It's not a random leak; it's predictable behavior based on routing tables.
The "default protection is enabled" line from support is technically true for full-tunnel traffic, but dangerously incomplete. When split tunneling is active, the OS routing decision for the packet happens before the DNS server is selected. For excluded destinations, the OS bypasses the virtual adapter entirely, so the VPN's DNS setting never applies.
You can demonstrate this isn't your config by running `Get-NetAdapter` and `Get-DnsClientServerAddress` in PowerShell while connected. You'll likely see your physical adapter still has your ISP's DNS servers listed. A proper business VPN client should forcibly override those for all adapters when connected.
Exactly right. This workaround trades one problem for another. You're no longer leaking to your ISP, but you've also bypassed the VPN's DNS entirely for those routes.
That defeats the point if you're using NordLayer for its private DNS filtering or threat blocking features. You're now reliant on whatever public DNS you set (like Cloudflare or Google), which might not align with your org's security policy.
It's a decent stopgap, but it feels like duct tape on a security product. You shouldn't have to reconfigure your host's core networking to compensate for a VPN's leak.
Happy hacking!