🔐 WireGuard Split-Tunnel VPN System

🎯 System Overview

This WireGuard VPN system implements a sophisticated split-tunnel architecture that intelligently routes different clients through different network paths based on their IP addresses. The system provides granular control over which traffic flows through a commercial VPN (OpenVPN provider) and which traffic goes directly to the internet, all while maintaining a unified WireGuard VPN interface for clients.

Core Design Principles

• IP-Based Traffic Separation: Traffic routing decisions are made based on source IP addresses, dividing the 10.4.0.0/24 subnet into two distinct groups
• Network Namespace Isolation: VPN-routed traffic is processed in an isolated Linux network namespace to prevent routing conflicts
• Transparent Routing: Clients require no special configuration beyond their IP assignment - routing happens automatically on the server
• Local Traffic Optimization: All local/private network traffic bypasses the VPN regardless of client type
• DNS Privacy: Custom DNS resolution with split-horizon DNS for internal services

🏗️ High-Level Architecture

🧩 Core Components

🌐 IP Address Allocation Strategy

Special Reserved Addresses

🔄 Data Flow & Packet Routing

Understanding how packets flow through this system is crucial to grasping its architecture. The routing decision happens at the server based on the packet's source IP, and clients are completely unaware of which path their traffic takes.

Scenario 1: Direct Internet Path (Client with IP 10.4.0.50)

Source: 10.4.0.50:54321 → Destination: 172.217.164.46:443

iptables -A FORWARD -i wg0 -s 10.4.0.0/25 -o ens5 -j ACCEPT

iptables -t nat -A POSTROUTING -s 10.4.0.0/25 -o ens5 -j MASQUERADE

Scenario 2: VPN-Routed Path (Client with IP 10.4.0.200)

Source: 10.4.0.200:54321 → Destination: 172.217.164.46:443

iptables -t mangle -A PREROUTING -i wg0 -m iprange --src-range 10.4.0.128-10.4.0.255 -j MARK --set-mark 0x200

ip rule add fwmark 0x200 table 200 priority 200

ip route add default via 10.200.1.2 dev veth-wg table 200

iptables -t nat -A POSTROUTING -m iprange --src-range 10.4.0.128-10.4.0.255 -o tun0 -j MASQUERADE

Scenario 3: Internal Traffic (Client-to-Client)

🌍 DNS Resolution Architecture

DNS resolution in this system is complex because it must handle three distinct scenarios: local domain resolution, VPN client DNS privacy, and the server's own DNS queries that need to traverse the VPN.

DNS Server Configuration (dnsmasq)

The dnsmasq server provides:

• Split-horizon DNS: Different responses for internal domains
• Multi-interface listening: Serves clients on wg0, namespace on veth-wg, and localhost
• Custom domain resolution: Local overrides for internal services
• Upstream forwarding: Queries for external domains forwarded to public DNS

DNS Resolution Paths

Path 1: Non-VPN Client DNS Query (Client 10.4.0.50)

Path 2: VPN Client DNS Query (Client 10.4.0.200)

iptables -t mangle -A OUTPUT -p udp --dport 53 -d 1.1.1.2 -j MARK --set-mark 0x100

iptables -t nat -A POSTROUTING -s 10.0.1.191 -d 1.1.1.2 -p udp --dport 53 -j SNAT --to-source 10.200.1.1

Path 3: Local Domain Query (Any Client)

Why DNS Queries Are Routed Through VPN

📦 Network Namespace Architecture

Network namespaces are a Linux kernel feature that provides complete network stack isolation. This system uses a namespace called vpn_ns to create a completely separate networking environment for VPN-routed traffic.

Why Namespaces Are Essential

Namespace Components

Namespace Lifecycle

Creation (wg0-up.sh)

1. Create namespace: ip netns add vpn_ns
2. Create veth pair: ip link add veth-wg type veth peer name veth-vpn
3. Move one end into namespace: ip link set veth-vpn netns vpn_ns
4. Configure IPs on both ends
5. Start OpenVPN inside namespace: ip netns exec vpn_ns openvpn ...
6. Configure routes inside namespace
7. Configure iptables inside namespace

Teardown (wg0-down.sh)

1. Stop OpenVPN process (kill PID)
2. Remove iptables rules inside namespace
3. Delete veth pair (automatically removes both ends)
4. Delete namespace: ip netns del vpn_ns
5. Clean up DNS config: rm -rf /etc/netns/vpn_ns

Viewing Namespace State

# List all namespaces
ip netns list

# Execute command in namespace
ip netns exec vpn_ns 

# View namespace interfaces
ip netns exec vpn_ns ip addr show

# View namespace routing table
ip netns exec vpn_ns ip route show

# View namespace iptables
ip netns exec vpn_ns iptables -L -n -v
ip netns exec vpn_ns iptables -t nat -L -n -v

# Check OpenVPN connection
ip netns exec vpn_ns ip addr show tun0
tail -f /var/log/openvpn-ns.log

🛣️ Policy-Based Routing

Policy routing (also called policy-based routing or PBR) is the mechanism that makes split-tunneling possible. Instead of routing decisions being based solely on destination addresses, policy routing allows decisions based on source address, packet marks, and other criteria.

The Linux Routing Policy Database (RPDB)

Linux maintains a database of routing rules that are checked in priority order. The first matching rule determines which routing table to use.

# View current routing rules
ip rule list

# Output from this system:
0:      from all lookup local                      # Priority 0 (always first)
100:    from 10.4.0.0/24 to 10.4.0.0/24 lookup main
101:    from all to 10.4.0.0/24 lookup main
102:    from all to 10.0.0.0/16 lookup main
103:    from all to 10.0.1.0/24 lookup main
104:    from all to 10.0.2.0/24 lookup main
200:    from all fwmark 0x200 lookup 200            # VPN client traffic
201:    from all fwmark 0x100 lookup 200            # DNS queries for VPN clients
32766:  from all lookup main
32767:  from all lookup default

Rule Priority Explanation

Custom Routing Table 200

Table 200 is created specifically for VPN-routed traffic:

# View table 200 routes
ip route show table 200

# Output:
default via 10.200.1.2 dev veth-wg

This simple default route sends all traffic in table 200 to the namespace (10.200.1.2 is the namespace end of the veth pair).

Why Priority Order Matters

🔄 NAT & Masquerading

Network Address Translation (NAT) is used extensively to allow multiple private IP addresses to share public IPs. This system employs NAT at multiple layers.

Layer 1: Host Namespace NAT (Direct Traffic)

For clients in the direct internet range (10.4.0.0-127):

iptables -t nat -A POSTROUTING -s 10.4.0.0/25 -o ens5 -j MASQUERADE

Effect: Translates source IPs from 10.4.0.0-127 to 10.0.1.191 (AWS instance private IP)

Then: AWS VPC performs additional NAT from 10.0.1.191 to the Elastic IP

Layer 2: VPN Namespace NAT (VPN Traffic)

Inside the vpn_ns namespace:

ip netns exec vpn_ns iptables -t nat -A POSTROUTING \
    -m iprange --src-range 10.4.0.128-10.4.0.255 -o tun0 -j MASQUERADE

Effect: Translates source IPs from VPN clients to the OpenVPN-assigned IP on tun0

Then: OpenVPN provider performs NAT from tun0 IP to the VPN exit node's public IP

Layer 3: DNS Query NAT

Special NAT for dnsmasq queries going through the VPN:

iptables -t nat -A POSTROUTING \
    -s 10.0.1.191 -d 1.1.1.2 -p udp --dport 53 \
    -j SNAT --to-source 10.200.1.1

Why Needed: dnsmasq (running on 10.0.1.191) sends DNS queries. When these queries need to go through the namespace, the source must be rewritten to 10.200.1.1 so responses can route back through the veth pair correctly.

Connection Tracking

All NAT operations rely on conntrack (connection tracking):

• Kernel maintains a table of all active connections
• For each outbound NATed packet, records the translation
• For inbound response packets, reverses the translation automatically
• Tracks connection state: NEW, ESTABLISHED, RELATED

# View all tracked connections
conntrack -L

# View connections through VPN namespace
ip netns exec vpn_ns conntrack -L

# Monitor new connections in real-time
conntrack -E

⏱️ System Lifecycle

Startup Sequence (wg0-up.sh)

Shutdown Sequence (wg0-down.sh)

Teardown happens in reverse order to prevent routing issues:

1. Stop OpenVPN: Kill process, wait for cleanup
2. Remove namespace iptables rules: NAT and mangle rules
3. Remove host iptables rules: Policy routing marks, NAT, forwarding
4. Remove policy routing rules: Clean RPDB
5. Flush custom routing table 200
6. Delete veth pair: Automatically removes both ends
7. Delete namespace: All namespace-specific configs gone
8. Clean up DNS config: Remove /etc/netns/vpn_ns

💼 Use Cases & Scenarios

Use Case 1: Privacy-Focused Browsing

Scenario: User wants to browse sensitive content without revealing their real IP

Solution: Assign WireGuard IP from VPN range (10.4.0.128-255)

Result: All browsing traffic exits through OpenVPN provider, DNS queries also anonymized

Use Case 2: Geo-Restricted Content

Scenario: Streaming service only available in certain countries

Solution: Use VPN range IP, select OpenVPN provider server in target country

Result: Service sees connection from VPN country

Use Case 3: Low-Latency Gaming

Scenario: Online gaming requires low latency, VPN adds too much overhead

Solution: Assign IP from direct internet range (10.4.0.0-127)

Result: Game traffic bypasses VPN, lowest possible latency

Use Case 4: Internal Service Access

Scenario: Access company internal services (vault.raff.local)

Solution: Any WireGuard IP works, DNS resolves to 10.4.0.7

Result: Traffic stays within WireGuard network, never reaches internet

Use Case 5: Split Configuration on Single Device

Scenario: User wants some apps through VPN, others direct

Solution: Device connects to WireGuard multiple times with different IPs

Advanced: Use network namespaces on client device, route apps differently

🔧 Configuration Variations

Variation 1: Different Split Ratios

The current 50/50 split can be adjusted:

• 75% VPN, 25% Direct: Change VPN_RANGE to 10.4.0.64-10.4.0.255
• 25% VPN, 75% Direct: Change VPN_RANGE to 10.4.0.192-10.4.0.255
• Update NON_VPN_SUBNET accordingly

Variation 2: Multiple VPN Providers

Could create multiple namespaces for different VPN providers:

• vpn_ns_nord: 10.4.0.128-191 → OpenVPN provider
• vpn_ns_express: 10.4.0.192-255 → ExpressVPN
• Create separate veth pairs and routing tables for each

Variation 3: Protocol-Based Routing

Instead of IP ranges, route based on protocol:

• HTTP/HTTPS through VPN: Mark TCP port 80/443
• Everything else direct
• Requires more complex iptables rules

Variation 4: Time-Based Routing

Route through VPN only during certain hours:

• Use iptables time matching: -m time --timestart 09:00 --timestop 17:00
• Conditionally apply packet marking

🔒 Security Model

Encryption Layers

Attack Surface Analysis

✅ Protected Scenarios

• ISP Surveillance: WireGuard encryption prevents ISP from seeing any client traffic
• Local Network Attacks: All traffic encrypted before leaving client device
• DNS Leaks: DNS queries for VPN clients route through VPN tunnel
• IP Address Exposure: VPN clients appear to come from OpenVPN provider exit nodes

⚠️ Potential Vulnerabilities

• AWS Can See Metadata: AWS can see connection to OpenVPN provider but not content (encrypted)
• OpenVPN provider Can See Traffic: VPN provider can see decrypted traffic (choose trusted provider)
• Direct-Internet Clients: These clients' traffic visible to AWS and ISP in metadata
• Correlation Attacks: Sophisticated attacker monitoring both ends could correlate timing

Firewall Rules

Principle of Least Privilege

• Namespace Isolation: OpenVPN runs in isolated namespace, can't access host network directly
• Separate Routing Tables: Each traffic path has its own rules, no cross-contamination
• Specific NAT Rules: Only necessary address translations permitted
• Granular Marking: Packets marked only for specific IP ranges