We recently ran a simulated breach drill, a tabletop exercise that escalated into a limited live-fire scenario. The goal was to trace an assumed compromised service account's lateral movement from a developer's laptop through our NordLayer-protected staging environment. The drill confirmed a significant, and frankly expensive, blind spot: NordLayer's connection logs are useless for forensic purposes when you need to identify a true source IP.
The scenario was straightforward. An actor (our red team) obtained credentials for a service account with access to a staging database. They connected from a residential ISP IP, using the NordLayer client configured for our organization's dedicated server. They performed a series of predictable actions: listing tables, downloading a schema dump. Our blue team's task was to identify the source of the breach using our available logs. We had the application logs showing the service account activity, and we had NordLayer's Team Admin portal logs.
Here's the problem in concrete detail. The NordLayer connection log provided an entry like this:
```
2024-05-15 14:22:17 UTC | member-xyz | connected | server-sfo-123 | 10.5.2.11
```
Great. So the user `member-xyz` connected to the NordLayer server `server-sfo-123` and was assigned the private IP `10.5.2.11`. Our application logs showed the connection coming from `10.5.2.11`. This is a perfect correlation that tells us exactly nothing we didn't already know. The critical piece—the original public IP address of the attacker's machine—is completely absent. It's been swallowed by NordLayer's network address translation. There is no "X-Forwarded-For" equivalent in their logged data.
We contacted support during the drill, posing as a panicked security admin. Their response was the boilerplate line: "For privacy and security, we do not log originating public IP addresses." This is marketed as a feature, but from an enterprise security perspective, it's a glaring deficit. It means you cannot:
* Correlate internal breach activity with external threat intelligence feeds.
* Geofence or IP-based blocklisting at your own infrastructure edge (you must rely entirely on NordLayer's gates, which lack the granularity).
* Perform any meaningful forensic timeline that extends outside your virtual private cloud.
The selling point of "privacy" is, in this context, a liability. We pay a premium for a business-tier service that ostensibly provides secure access, but it actively hinders our ability to investigate misuse of that very access. The architecture makes sense for individual privacy; it's fundamentally at odds with the internal security and audit requirements of any organization that handles sensitive data.
We've had to work around this by mandating that all access to sensitive resources must be further proxied through an internal bastion host that we control and log comprehensively, which rather defeats the purpose of a seamless, managed zero-trust network solution. Now we're just using an expensive, convoluted VPN.
If your threat model includes malicious insiders or compromised credentials, and you have any compliance requirements around audit trails, NordLayer's logging will leave you with an unacceptably shallow trail.
-- Cam
Trust but verify.