I've been running NordLayer for about six months now, primarily to secure access to our analytics database clusters from distributed team members. I was drawn in by the promise of a "simple" setup, especially compared to some of the heavier enterprise VPN solutions.
My experience has been... educational. The core connection works fine, but the actual configuration for anything beyond basic per-user tunneling has some surprising complexities that aren't well-documented upfront. I've ended up maintaining a small internal wiki just for our team's gotchas.
A few specific pain points I ran into:
* **Route configuration:** Setting up split tunneling for specific apps (like only our database client) required manually editing config files. The GUI toggle is all-or-nothing for "allow local network," which isn't granular enough.
* **Service account automation:** Automating connections for CI/CD pipelines was more cumbersome than expected. The token rotation and permission scoping felt bolted on, not built-in.
* **Logging:** Getting detailed connection logs to debug a latency issue meant combing through system logs, as the admin panel mostly shows connection status, not performance or routing details.
It gets the job done, and the performance is decent once everything is dialed in. But "simple" isn't the word I'd use. It's simple *if* your use case perfectly matches their default setup. The moment you need to deviate, you're in for some configuration archaeology.
Has anyone else hit similar configuration walls? I'm particularly curious if others have found elegant workarounds for the split-tunneling granularity issue.
Oh, I hear you on the split tunneling part! That's a classic case where the marketing 'simple' button meets real-world 'specific' needs. I had a similar hurdle trying to get it to only tunnel our design team's Figma app, while leaving everything else on the local network.
Your point about service accounts for CI/CD is especially valid. That process felt like an afterthought, didn't it? I ended up creating a separate, limited 'automation' team just to scope those permissions, which is a workaround, not a feature.
And the logging - yes! The admin panel gives you the 'what' (connected), but never the 'how well' (latency, packet loss). Had to do the same system log dive during a weird peak-time slowdown. Makes you wonder if they consider that an 'advanced' feature they can charge extra for later.
You've perfectly captured the issue with the service account setup feeling like an afterthought. Creating a separate 'automation' team is a clever workaround, but it shouldn't be necessary for a core enterprise function.
I hadn't considered the logging point in quite that light, but you're right. The lack of performance data in the admin panel turns simple troubleshooting into a forensic exercise. It creates a real blind spot for team leads trying to diagnose quality of service issues.
Maybe the disconnect is that their definition of 'simple' is 'it connects,' while ours includes 'it connects reliably and we can see why when it doesn't.'
No receipts, no trust.