Zero Trust Home Network with Twingate: No VPN Required

Last updated: July 10, 2026 | Reading time: 8 minutes

Introduction: Why VPNs Are Broken for Homelabs

Traditional VPNs are fundamentally flawed for modern homelab access:

All-or-nothing access - Once connected, you're on the entire network
Single point of failure - VPN down = no access to anything
Complex setup - Port forwarding, dynamic DNS, certificate management
Security risks - Exposed VPN ports are constant attack vectors
Poor mobile experience - Battery drain, connection drops, manual reconnect

Zero Trust solves all of this. Instead of "trust everyone inside the network," Zero Trust assumes no one is trusted—every access request is verified, every connection is encrypted, and users only see what they're explicitly allowed to access.

This guide shows you how to implement Zero Trust for your homelab using Twingate—no port forwarding, no exposed IPs, no VPN client headaches.

What is Zero Trust?

Zero Trust is a security model built on three principles:

Never trust, always verify - Every access request is authenticated and authorized
Least privilege access - Users only access what they explicitly need
Assume breach - Design as if attackers are already inside the network

For homelabs, this means:

No open ports on your router
Each service has individual access controls
Remote users can't see your entire network
Audit logs for every connection

Why Twingate?

I evaluated several Zero Trust solutions:

| Solution | Cost | Complexity | Homelab Fit | |----------|------|------------|-------------| | Twingate | Free tier (5 users) | Low | ⭐⭐⭐⭐⭐ | | Tailscale | Free tier (3 users) | Low | ⭐⭐⭐⭐ | | Cloudflare Zero Trust | Free tier (50 users) | Medium | ⭐⭐⭐⭐ | | Ziti (OpenZiti) | Free (self-hosted) | High | ⭐⭐⭐ | | WireGuard + Auth | Free | High | ⭐⭐ |

Twingate wins for homelabs because:

Free for up to 5 users and 10 resources
5-minute setup (literally)
No client required for web services (browser-based access)
Works behind NAT (no public IP needed)
Granular access controls per service
Full audit logging

Architecture Overview

Here's how Twingate works in a homelab:

┌─────────────────┐
│   Remote User   │
│   (Laptop/Phone)│
└────────┬────────┘
         │ Encrypted TLS
         ▼
┌─────────────────┐
│  Twingate Cloud │
│  (Control Plane)│
└────────┬────────┘
         │ Secure tunnel
         ▼
┌─────────────────┐
│  Twingate       │
│  Connector      │
│  (Your Homelab) │
└────────┬────────┘
         │ Local network
         ▼
┌─────────────────┐
│  Your Services  │
│  (Proxmox,      │
│   Jellyfin,     │
│   Gitea, etc.)  │
└─────────────────┘

Key points:

The Connector runs in your network (Docker, VM, or bare metal)
It creates outbound-only connections to Twingate (no inbound ports)
Users authenticate with Twingate Cloud
Access is granted per-resource, not per-network

Step 1: Create Your Twingate Network

Go to twingate.com
Click Get Started Free
Sign up with email or SSO (Google, Microsoft, Okta)
Create your network name (e.g., "neuralcodelab-homelab")

You'll land in the admin console.

Step 2: Deploy the Connector

The Connector is a lightweight service that routes traffic to your resources.

Option A: Docker (Recommended)

# Create directory
mkdir -p ~/docker/twingate-connector
cd ~/docker/twingate-connector

# Get tokens from Twingate console
# Go to Connectors → Add Connector → Copy tokens

# Create docker-compose.yml
cat > docker-compose.yml << EOF
version: '3'
services:
  twingate-connector:
    image: twingate/connector:latest
    container_name: twingate-connector
    restart: unless-stopped
    environment:
      - TWINGATE_NETWORK=your-network-name
      - TWINGATE_ACCESS_TOKEN=your-access-token
      - TWINGATE_REFRESH_TOKEN=your-refresh-token
    dns:
      - 1.1.1.1
      - 8.8.8.8
EOF

# Start
docker compose up -d

Option B: LXC Container (Proxmox)

# Create Ubuntu 24.04 container
# 1 CPU, 512 MB RAM, 4 GB disk

# Inside container:
docker run -d \
  --name twingate-connector \
  --restart unless-stopped \
  -e TWINGATE_NETWORK=your-network-name \
  -e TWINGATE_ACCESS_TOKEN=your-access-token \
  -e TWINGATE_REFRESH_TOKEN=your-refresh-token \
  --dns 1.1.1.1 \
  --dns 8.8.8.8 \
  twingate/connector:latest

Option C: Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: twingate-connector
spec:
  replicas: 1
  selector:
    matchLabels:
      app: twingate-connector
  template:
    metadata:
      labels:
        app: twingate-connector
    spec:
      containers:
      - name: connector
        image: twingate/connector:latest
        env:
        - name: TWINGATE_NETWORK
          value: "your-network-name"
        - name: TWINGATE_ACCESS_TOKEN
          valueFrom:
            secretKeyRef:
              name: twingate-secrets
              key: access-token
        - name: TWINGATE_REFRESH_TOKEN
          valueFrom:
            secretKeyRef:
              name: twingate-secrets
              key: refresh-token
        dnsPolicy: ClusterFirst
        dnsConfig:
          nameservers:
            - 1.1.1.1
            - 8.8.8.8

Step 3: Add Resources

Resources are the services you want to protect.

Add a Resource

Go to Resources → Add Resource
Configure:
- Name: Proxmox (user-friendly name)
- Address: 192.168.1.100:8006 (internal IP:port)
- Visible to: Select which users/groups can access
Click Save

Example Resources for Homelab

| Resource Name | Address | Access | |---------------|---------|--------| | Proxmox | 192.168.1.100:8006 | Admin only | | Gitea | 192.168.1.101:3000 | All users | | Grafana | 192.168.1.102:3000 | All users | | Jellyfin | 192.168.1.103:8096 | Family only | | Nextcloud | 192.168.1.104:443 | All users | | SSH Gateway | 192.168.1.100:22 | Admin only |

Step 4: Add Users

Go to Users → Add User
Enter email address
Select groups (create groups for access control)
Click Send Invite

Users receive an email with setup instructions.

Recommended Groups

| Group | Access Level | Members | |-------|--------------|---------| | Admins | Full access to all resources | You | | Developers | Dev services (Gitea, CI/CD, etc.) | Your team | | Family | Media services only | Family members | | Guests | Limited, temporary access | Visitors |

Step 5: Install the Client

Desktop Client (Windows/Mac/Linux)

User clicks invite link
Downloads Twingate client
Logs in with email
Can now access resources

Mobile Client (iOS/Android)

Same process—download app, log in, connect.

Browser Access (No Client)

For web services, Twingate offers browser-based access:

Enable Browser Session for the resource
Users click "Access via Browser" in Twingate app
Service opens in isolated browser session
No client installation needed

Security Best Practices

Enable MFA

Force multi-factor authentication:

Go to Settings → Security
Enable Require MFA
Choose methods: TOTP (Google Authenticator), SMS, or SSO

Set Resource Access Policies

Don't give everyone access to everything:

Go to Resources → Select resource
Click Access tab
Configure:
- Required Approvals: Who must approve access
- Allowed Groups: Which groups can request access
- Time-limited access: Auto-revoke after X hours

Enable Audit Logging

Twingate logs every connection:

Go to Reports → Audit Logs
Export logs for compliance
Set up alerts for suspicious activity

Use Split Tunnel

By default, only Twingate resources route through the tunnel. Your regular internet traffic goes directly—no speed impact.

Advanced: Self-Hosting the Connector

For full control, run the Connector on your infrastructure.

System Requirements

1 vCPU
512 MB RAM
2 GB disk
Outbound internet access (ports 443, 11800-11810)

Docker Compose with Health Checks

version: '3'
services:
  twingate-connector:
    image: twingate/connector:latest
    container_name: twingate-connector
    restart: unless-stopped
    environment:
      - TWINGATE_NETWORK=${TWINGATE_NETWORK}
      - TWINGATE_ACCESS_TOKEN=${TWINGATE_ACCESS_TOKEN}
      - TWINGATE_REFRESH_TOKEN=${TWINGATE_REFRESH_TOKEN}
      - TWINGATE_LOG_LEVEL=3
    dns:
      - 1.1.1.1
      - 8.8.8.8
    healthcheck:
      test: ["CMD", "pgrep", "-f", "twingate"]
      interval: 30s
      timeout: 10s
      retries: 3
    networks:
      - twingate-net

networks:
  twingate-net:
    driver: bridge

Monitoring the Connector

# Check status
docker logs twingate-connector

# View connections
docker exec twingate-connector netstat -tlnp

# Restart if needed
docker restart twingate-connector

Comparison: Twingate vs Traditional VPN

| Feature | Twingate | Traditional VPN | |---------|----------|-----------------| | Setup time | 5 minutes | 1-2 hours | | Port forwarding | Not required | Required | | Public IP exposure | None | VPN port exposed | | Access granularity | Per-resource | All-or-nothing | | Mobile experience | Excellent | Poor | | Audit logging | Built-in | Manual setup | | MFA | Built-in | Additional config | | Cost (5 users) | Free | $50-200/month |

Troubleshooting

Connector Won't Start

Check tokens:

docker logs twingate-connector
# Look for "authentication failed"

Regenerate tokens in Twingate console and restart.

Can't Access Resources

Verify resource address is correct
Check user has access to the resource
Ensure Connector has outbound internet access
Test from inside the network first

Slow Connections

Check Connector CPU/memory usage
Verify internet bandwidth
Try different Twingate PoP (Point of Presence)

Conclusion

Zero Trust with Twingate gives you:

✅ No open ports on your router
✅ Granular access per service
✅ Full audit logging
✅ Works from anywhere (no public IP needed)
✅ Free for homelab use (5 users)

The setup takes 15 minutes end-to-end. There's no reason to keep running a traditional VPN in 2026.

Next steps:

Deploy the Connector
Add your first resource (Proxmox or Gitea)
Invite one test user
Verify access works
Add remaining resources gradually

Questions? Drop them below. Found this helpful? Share it with someone still using OpenVPN.