I've been evaluating NordLayer as a potential solution for securing developer access to our cloud environments. My primary use case is to enforce IP whitelisting for administrative consoles, specifically our Cloudflare Access policies.
The setup appears straightforward: I connect to a dedicated NordLayer gateway server, note the static IP provided, and add that IP to the Cloudflare Access rule's allowed IP list. However, authentication consistently fails when attempting to reach the protected resource. The connection from the NordLayer client is established, but Cloudflare does not seem to recognize the traffic as originating from the whitelisted IP.
I have conducted a methodical isolation test:
* Verified the static gateway IP is correct using multiple external IP check services while connected.
* Confirmed the Cloudflare Access policy is set to "Allow" for that specific IP, with no other conflicting rules.
* Tested the same policy with my own office static IP, which works without issue.
* Ensured NordLayer's "Local network access" setting is enabled, as disabling it blocks all outgoing traffic.
This suggests a potential routing issue where the egress traffic from the NordLayer VPN is not truly originating from the advertised gateway IP, or perhaps a TCP/IP packet header is being manipulated in a way Cloudflare can detect.
Has anyone successfully implemented this specific integration? I am particularly interested in:
* Any required NordLayer agent configuration nuances.
* Whether Cloudflare's WARP client interacts negatively with NordLayer.
* If using the "Relay" protocol option versus "OpenVPN" makes a difference.
Without a functional IP whitelist, the core finops justification for this tool—replacing a more expensive bastion host setup—becomes untenable.
Your bill is too high.
This exact scenario tripped me up for a good while. Even with the correct gateway IP in the allow list, it was still failing. The issue for me was that the NordLayer application, at least on Windows, was still allowing some local traffic to bypass the tunnel for certain services. Try setting the Kill Switch to 'Always On' within the NordLayer client settings. That forces *all* traffic through the tunnel, which fixed the inconsistent IP detection for Cloudflare. It's a bit more aggressive but works.
Connecting the dots.
> Verified the static gateway IP is correct using multiple external IP check services while connected.
Those services can be misleading when a VPN is involved. They're reporting the egress IP of the VPN tunnel itself, but they don't account for how your specific client traffic routes to that tunnel endpoint. I'd suggest running a more direct test from the affected machine.
Open a command line and run `curl -s https://cloudflare.com/cdn-cgi/trace | grep ip`. Do this while connected to NordLayer. This will show you the IP that Cloudflare's own infrastructure sees for the request, which is the definitive value for Access policy evaluation. If this differs from your static gateway IP, the issue is client-side routing, not the policy. A common culprit is the client's split-tunnel configuration or DNS leakage.
Your isolation test is methodical, and the fact your office IP works confirms the Access policy logic is sound. The discrepancy points squarely to a routing nuance you've started to uncover.
The key observation is that NordLayer's client, like many commercial VPNs, can exhibit split-tunneling behavior even when not explicitly configured. The "Local network access" setting you enabled is primarily for LAN discovery; it doesn't guarantee all WAN traffic is forced through the tunnel. Background services, DNS queries, or even certain browser connections might still egress via your local default route.
I'd build on the `curl` test suggested by user1314. Run it directly from the machine experiencing the block. If the returned IP doesn't match your NordLayer gateway IP, you have definitive proof of a client-side leak. The next step would be to inspect the routing table (`netstat -rn` or `ip route`) while connected to NordLayer to see if a non-tunnel default route persists.
Ultimately, forcing all traffic through the tunnel via a kill switch, as user1243 mentioned, is often the only reliable fix for this specific whitelisting use case. It removes the variable of the client's local routing decisions.
infra nerd, cost hawk
The `curl` test is the definitive check, but I'd argue `dig TXT o-o.myaddr.l.google.com @ns1.google.com` from the same machine is more reliable for proving the actual outbound IP. Some CDN edges or corporate proxies can influence the `cloudflare.com/trace` result.
If the kill switch solves it, your baseline configuration is fundamentally broken for a whitelisting requirement. You shouldn't need to rely on an emergency feature for basic traffic shaping. It points to a flawed default routing table push from the client.