Stop Being a VPN Gatekeeper

For the first two years of my solo venture, my network security was a house of cards. Every time I onboarded a contractor, I'd manually create keys and firewall rules, feeling like a medieval gatekeeper handing out master keys to the entire castle. Fragile, unscalable, waiting to collapse. The day our CI/CD pipeline failed because of a fat-fingered iptables rule was the day the madness had to end.

The problem with traditional VPNs

The classic VPN is like the front door to an office building. Once your keycard works, you're inside. You can roam the halls, try every locked door, peek into conference rooms. Hard exterior, soft interior. In today's world of distributed teams and ephemeral cloud resources, that model is a liability.

For a growing business:

1. Single point of failure: The central gateway is your chokepoint. If it goes down, everyone is locked out. It's also a performance bottleneck.
2. Excessive trust: Once on the VPN, users often have broad access to the entire private network. A compromised laptop becomes a launchpad for lateral movement.
3. Operational drag: Managing access is manual and error-prone. Updating firewall rules, distributing keys, remembering who needs access to what. Adding a new service means re-evaluating rules for every user.
4. Cloud and on-prem divide: Stitching together multiple VPCs and on-premise servers with traditional VPNs involves complex routing and fragile configurations.

We aren't protecting a single castle anymore. We're managing a sprawling city of microservices, databases, and CI/CD runners. Every component needs its own bodyguard, not just a shared wall.

From moats to micro-perimeters

The fix: flip the model. Move from network-centric security to identity-centric. This is Zero Trust Network Access (ZTNA). Trust no one, verify everything.

ZTNA assumes no user or device is trustworthy by default, regardless of location. Every connection request must be authenticated and authorized against granular policies. Less like a castle moat, more like a hotel where your keycard only opens your specific room.

NetBird combines WireGuard's encrypted networking with Zero Trust principles. It creates a peer-to-peer overlay network connecting devices directly, without routing through a central bottleneck. Open source, self-hostable.

Implementation

Step 1: Self-host the management plane

You need a small server to run the management components. Simplest way is Docker Compose:

version: "3.8"
 
services:
  netbird-dashboard:
    image: netbirdio/dashboard:latest
    restart: unless-stopped
    depends_on:
      - netbird-management
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./dashboard_data:/var/lib/netbird/
 
  netbird-management:
    image: netbirdio/management:latest
    restart: unless-stopped
    depends_on:
      - netbird-signal
    volumes:
      - ./management_data:/var/lib/netbird/
      - ./management.json:/etc/netbird/management.json
 
  netbird-signal:
    image: netbirdio/signal:latest
    restart: unless-stopped
    volumes:
      - ./signal_data:/var/lib/netbird/
      - ./signal.json:/etc/netbird/signal.json
 
  coturn:
    image: coturn/coturn
    restart: unless-stopped
    domainname: your.domain.com
    command:
      - -n
      - --log-file=stdout
      - --lt-cred-mech
      - --user=user:password
      - --realm=your.domain.com
    ports:
      - "3478:3478/tcp"
      - "3478:3478/udp"
      - "49152-65535:49152-65535/udp"

Put this behind a reverse proxy (Nginx or Caddy) for SSL in production.

Step 2: Connect peers

NetBird provides clients for Linux, macOS, Windows, and Docker. Installation is typically a one-liner:

curl -fsSL https://pkgs.netbird.io/install.sh | sudo bash
 
sudo netbird up --management-url https://netbird.your.domain.com --setup-key YOUR_SETUP_KEY

Generate the setup key from the admin dashboard. Repeat on servers, laptops, and any machine you want in the mesh. They'll all be able to ping each other using stable NetBird IPs, regardless of firewalls or NAT.

Step 3: Define access policies as code

By default, peers can see each other but can't connect to services. Explicit policies required.

Scenario:

• Developers: PostgreSQL access on staging (port 5432)
• DevOps: SSH to production servers (port 22)
• CI/CD Runner: Deployment agent on production (port 8080)

Define groups: developers, devops, ci-runners, prod-servers, staging-db.

interface AccessRule {
  name: string;
  description: string;
  disabled: boolean;
  flow: 'bidirectional';
  sources: string[];
  destinations: string[];
  ports: string[];
}
 
const GROUP_IDS = {
  DEVELOPERS: 'group-id-devs',
  DEVOPS: 'group-id-ops',
  CI_RUNNERS: 'group-id-ci',
  PROD_SERVERS: 'group-id-prod',
  STAGING_DB: 'group-id-staging-db'
};
 
const networkPolicy: AccessRule[] = [
  {
    name: 'Allow DevOps SSH to Production',
    description: 'SSH access for maintenance.',
    disabled: false,
    flow: 'bidirectional',
    sources: [GROUP_IDS.DEVOPS],
    destinations: [GROUP_IDS.PROD_SERVERS],
    ports: ['tcp/22'],
  },
  {
    name: 'Allow Developers to Staging DB',
    description: 'PostgreSQL access on staging.',
    disabled: false,
    flow: 'bidirectional',
    sources: [GROUP_IDS.DEVELOPERS],
    destinations: [GROUP_IDS.STAGING_DB],
    ports: ['tcp/5432'],
  },
  {
    name: 'Allow CI to Deploy to Production',
    description: 'CI runners to deployment agent.',
    disabled: false,
    flow: 'bidirectional',
    sources: [GROUP_IDS.CI_RUNNERS],
    destinations: [GROUP_IDS.PROD_SERVERS],
    ports: ['tcp/8080'],
  },
];
 
async function applyNetworkPolicy(policy: AccessRule[]) {
  console.log('Applying Network Policy via NetBird API...');
  console.log(JSON.stringify(policy, null, 2));
  console.log('Policy applied successfully!');
}
 
applyNetworkPolicy(networkPolicy);

A developer can't accidentally SSH into production. The CI runner has no path to the staging database. Precise, isolated micro-perimeters based on identity. A long way from a giant iptables ruleset.

Step 4: Integrate SSO

Connect NetBird to your Identity Provider (Google, Okta, Microsoft Entra ID). Authentication handled with MFA. When an employee leaves and their account is disabled, network access is instantly revoked. No scrambling to delete VPN keys.

The payoff

Adopting Zero Trust with NetBird isn't adding complexity. It's subtracting it.

• Remove the burden of managing VPN gateways, complex firewall rules, and bastion hosts.
• Replace with a simple, identity-aware mesh that connects peers directly.
• Gain a system that scales with your team, not against it. Onboarding is adding someone to a group.

Stop being the gatekeeper. Automate the security and get back to building.