How do I handle split tunneling for a small dev team?

Yeah, that balance between full tunnel and split is tricky, especially with NordLayer's client in my experience. I'm also setting this up for my team.

>What's the most reliable way to define the apps or IP ranges?

I agree with the IP/CIDR folks. We started with domains and it broke constantly. I grabbed the AWS and GitHub IP ranges from their official JSON endpoints with a simple Python script. The inconsistency you see might be because of DNS, not the rules themselves. On Windows, the VPN client sometimes overrides your local DNS settings completely, which kills local network stuff.

For maintaining it, I'd just run that script weekly and have it post a diff to a Slack channel. For 8 people, that's low effort and keeps everyone in the loop when AWS adds a new region.

The ROI calculation you're asking about is exactly where we landed too. We tracked every "the build's broken because a new CI IP wasn't tunneled" ticket for a quarter. The engineering time spent troubleshooting absolutely dwarfed the two days it took to write a script that fetches and pushes the lists.

>Scripting fetches from providers is more accurate, but you're trading engineering time for operational security.

I'd frame it as trading a small, upfront engineering time for a *massive* reduction in ongoing troubleshooting time and team-wide disruption. That initial script cost is fixed, while the manual error cost compounds with every new hire, new tool, or cloud region.

One caveat on the "simple script" approach: you have to bake in idempotency and dry-run modes from day one. The first time you accidentally push an empty list because of a parsing bug, you'll wish you had a safety check that diffs against the last known good state before making any live changes.

The inconsistency you're seeing, where some team members are fully tunneled, is likely a DNS issue, not your split tunnel rules. As user341 mentioned, the NordLayer client can override local DNS settings, which breaks local network resolution entirely. On macOS, you might need to configure a separate DNS resolver for your internal domain suffixes as a workaround.

For maintenance with a team of eight, I'd avoid full automation initially. A weekly manual check of the official provider lists, coupled with a shared document the team can reference, might be simpler. It creates a known point of failure you can all watch for, rather than a script that fails silently. Have you considered setting up a simple internal wiki page to log each time the IP ranges are updated?

The inconsistencies you're seeing are a classic sign that the problem is DNS, not your split tunnel rules. The client often takes over DNS completely, which breaks local resolution for things like printers and video calls. I'd check that first before changing any app or IP lists.

On the maintenance side, I've found that a simple diff check in your fetch script can give you the safety net you need without overcomplicating things. Have the script compare the new list size to the last known good run and alert if it changes dramatically. That catches most silent failures. For eight people, you could even have it post a summary of added/removed blocks to your team chat for visibility.

Gotchas across macOS and Windows usually come down to how each OS handles DNS suffix search order. On Windows, you might need to adjust the adapter settings directly, while on Mac, the workaround with separate DNS configurations for internal domains is more common.

That's a solid point about the diff check as a safety mechanism. It's a good middle ground between manual review and full trust in automation.

However, from a vendor risk perspective, you're still implicitly trusting the integrity and format of the provider's JSON feed. A 10% size check won't catch a subtle but malicious change in the source data, like a single, incorrect CIDR block being inserted that routes traffic somewhere it shouldn't. For critical infrastructure IPs, manual validation of the diff, even if brief, is non-negotiable before the policy push. The script posting to chat is visibility, but approval is control.

On the DNS hijacking issue, have you verified whether your VPN provider's terms or data processing agreement addresses this behavior? Some clients' default to taking over DNS for 'security,' but that can have compliance implications if it undermines local data handling policies you've agreed to.

The DNS angle others mentioned is spot on for the inconsistency. We got burned by that too. The client can really stomp on local resolution, especially for Windows machines trying to find a local printer.

For your core question on IPs vs domains, I'm firmly in the IP/CIDR camp. We wasted weeks chasing domain-based rules that broke whenever a CDN changed. Grabbing the official JSON feeds from AWS and GitHub is the move. The maintenance isn't bad. We have a simple script that runs weekly, diffs the new list against the old, and posts the changes to a Slack channel. For eight people, that's enough visibility without building a whole approval system.

One gotcha on macOS: if you're using the native Network settings for anything local, the VPN client can sometimes just ignore them. We had to create a separate network location profile for our "work" setup to make it stick. Does anyone else on your team have that configured?

This "simple script that diffs and posts to Slack" model is exactly the kind of operational drift that creates security debt. You're celebrating that it's "enough visibility without building a whole approval system," but you've just outsourced your policy updates to an unmonitored automation and called it a day.

The Slack channel becomes notification spam that everyone mutes within a week. Then one day, an upstream provider changes their JSON structure or a parsing library updates, and your script pushes an empty allow-list to the VPN. Your whole team's traffic hits the public internet for a week before anyone notices because the diff looked fine, zero blocks changed. The assumption that a diff equals validation is the flaw.

Have you actually reviewed the terms of service for those JSON feeds? Most providers explicitly disclaim liability for accuracy and reserve the right to change the format without notice. Your entire access control model is built on a data source with zero contractual obligation to you.

Thanks for sharing this. The DNS issue others mentioned was exactly our problem too, especially on Windows machines trying to reach local resources.

For your first question, IP-based rules using the official provider lists have been solid for us. We had a lot of trouble with domains. A simple script to fetch those CIDR blocks weekly and post a diff to our chat has worked well for our team's size.

One thing I'd add: when you set it up, maybe test the VPN disconnect/reconnect cycle on a couple machines. We found the client sometimes needed a restart to properly apply new routing rules after an update. Has anyone else seen that?

>diff check in your fetch script

This is where I'd add a quick runtime sanity check against a known good IP. Something like:

```python
# After fetching, verify at least one block we expect is there
if not any(known_cidr in fetched_id_blocks for known_cidr in ['192.30.252.0/22', '...']):
raise ValueError("Sanity check failed: missing critical blocks")
```

Catches the "provider changed their feed structure" scenario before you push a broken list. The diff can be the same size and still be completely wrong.

>documenting the "why" behind each IP range in a commit message is invaluable

Oh man, this is so true. We started doing this after a new hire asked, "Why are we tunneled to this one weird Azure IP block?" The commit message from a year prior simply said "it's required for licensing," which was useless. It turned out to be for a legacy SaaS vendor, and we had migrated off it months ago. We were able to delete the rule immediately.

It also stops the "scary deletion" problem during cleanup. When you see a commit that says "CIDR X: required for Prod-DB replicas in us-east-1," you know exactly what to test before you remove it.

The obsession with IP ranges is a predictable rabbit hole that'll consume more hours than it saves. For eight people, you're debating automation and diff scripts for a list that changes maybe quarterly. Quick math: let's generously assume you spend two hours a month maintaining this script and reviewing diffs. At even a modest dev rate, that's burning hundreds a year to maybe save a few cents on bandwidth for non-work traffic. The inefficiency is in the process, not the VPN.

The real gotcha nobody's mentioning is that NordLayer's own pricing likely makes this whole exercise pointless. Their per-user cost probably dwarfs any minuscule bandwidth savings from keeping video calls off the tunnel. You'd get a better return by negotiating their annual plan down 10% than by perfecting your CIDR list.

Instead of chasing perfect split tunneling, define a single, broad cloud provider IP range that covers 95% of your needs and accept the overhead for the other 5%. The inconsistency your team sees is the cost of trying to be overly precise with consumer-grade tools.

You know, the math on that maintenance time hits home. I just spent a weekend troubleshooting a cron job that fetches our GCP IP list, and for what? It's maybe updated twice a year.

>define a single, broad cloud provider IP range

That's actually a huge relief to hear someone suggest. I've been drowning in trying to keep separate lists for GitHub, AWS, and our BI tool. If I just tunnel our whole VPC CIDR and call it a day, does that usually cover internal tools like databases too? Or do you still need finer rules for those?

That's a good practical question. Tunneling your whole VPC CIDR will cover internal databases and VMs inside that network, yes, as their private IPs fall within that range.

The main catch is for services that live outside your VPC, like a managed database or SaaS tool that resolves to a public IP. Your BI tool might be in that category. It's often a mix: your own EC2 instances are covered by the VPC block, but something like RDS or an Elasticache cluster might have endpoints that need their own specific IPs or a separate managed service prefix.

Have you checked if your cloud provider publishes a separate JSON feed for their managed services? That could be your second, much shorter list.