Avoiding Disconnection When Redirecting Default Gateway in OpenVPN Static Key Mode

💡 Introduction

In small office environments or for quick site-to-site links, it’s common to deploy OpenVPN in Static Key Mode.
This setup is simple — it only requires a shared key file and no certificate authority. It’s ideal for lightweight, point-to-point encrypted tunnels.

However, when you want laptop users to route all traffic through the OpenVPN server (full-tunnel mode), you may encounter a frustrating issue:

Once the user accepts the default gateway, the VPN disconnects.

This article explains why that happens, and shows how to configure it correctly to achieve stable full-tunnel VPN connections.

🔍 The Root Cause — Why the VPN Disconnects

In OpenVPN, if the client replaces its default gateway with the VPN (for example, route 0.0.0.0 0.0.0.0 10.40.0.1),
then all packets, including the control channel packets (UDP 37000), are routed through the tunnel.

Since the control channel itself is not yet established, those packets can’t reach the server — resulting in an immediate disconnect.

This is why forum posts often say “enabling default gateway makes the VPN drop.”
The real issue is routing, not OpenVPN itself.

⚙️ Understanding Static Key Mode

Static Key Mode is the simplest OpenVPN topology:

Both sides share a single secret key (secret /etc/openvpn/ns01.key)
Generate Static Key (openvpn –genkey –secret ns01.key)
No certificates or TLS handshake
No push capability — the server cannot send routes or DNS settings to the client
All routing must be manually defined in the client configuration

Therefore, in static key mode, full-tunnel routing can only be achieved manually.

✅ Example Server Configuration

port 37000
proto udp
dev tun

secret /etc/openvpn/ns01.key
ifconfig 10.40.0.1 10.40.0.2

keepalive 10 60
ping-timer-rem
persist-tun
persist-key

mssfix 1450
compress lz4
verb 3
daemon
user nobody
group nobody

# Enable IP forwarding and NAT on the host system:
# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -s 10.40.0.0/24 -o eth0 -j MASQUERADE

🔸 System-level setup

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.40.0.0/24 -o eth0 -j MASQUERADE

This ensures that VPN client traffic from 10.40.0.0/24 can reach the internet via NAT.

✅ Client Configuration — The Key: Preserve the Control Channel Route

remote <server_public_ip> 37000
proto udp
dev tun
secret ns01.key

ifconfig 10.40.0.2 10.40.0.1

# 🌐 Key #1: Keep a direct route to the server’s public IP
route remote_host 255.255.255.255 net_gateway

# 🌐 Key #2: Send all other traffic through the VPN
route 0.0.0.0 0.0.0.0 10.40.0.1

persist-tun
persist-key
ping 10
ping-restart 60

mssfix 1450
verb 3

🔍 Explanation

route remote_host automatically refers to the remote server IP.
net_gateway is an OpenVPN built-in variable that represents the system’s default physical gateway —
the router currently used by the laptop (home Wi-Fi, office LAN, or mobile hotspot).
These two directives ensure:
- Control packets go out via the real network interface.
- All user traffic (web, ERP, mail, etc.) goes through the VPN tunnel.

Result:
A stable control channel and a full-tunnel VPN connection.

🧩 Checking the Routing Table

After connection, run:

ip route

Expected output:

default via 10.40.0.1 dev tun0
10.40.0.0/24 dev tun0 proto kernel scope link src 10.40.0.2
<server_public_ip>/32 via <local_gateway> dev wlan0

The last line is the preserved host route that keeps the VPN control channel alive.

🚀 Advanced: Emulating `redirect-gateway def1`

To mimic the behavior of TLS mode’s redirect-gateway def1, you can use:

route remote_host 255.255.255.255 net_gateway
route 0.0.0.0 128.0.0.0 10.40.0.1
route 128.0.0.0 128.0.0.0 10.40.0.1

This adds two /1 routes instead of a single default route,
but in most cases, route 0.0.0.0 0.0.0.0 10.40.0.1 works perfectly fine.

🔒 Bonus Tip: Consider TLS Mode for Better Stability

If you’re open to using certificates and CA infrastructure,
switching to TLS mode simplifies everything:

Server

server 10.40.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 1.1.1.1"

Client

client
remote <server_ip> 37000
dev tun
proto udp
ca ca.crt
cert client.crt
key client.key

The server automatically handles host routes — no manual routing needed.
For simple one-to-one links, static key mode remains fine;
for multiple or roaming users, TLS mode is strongly recommended.

⚠️ Common Pitfalls and Fixes

Issue	Root Cause	Fix
VPN disconnects immediately	Control channel routed into VPN	Add `route remote_host ... net_gateway`
Client can ping VPN but not the internet	Missing NAT or IP forwarding	Enable `net.ipv4.ip_forward` and add MASQUERADE
Connection unstable or slow	MTU/MSS too high	Add `mssfix 1450`
Home LAN conflicts with VPN subnet	Overlapping routes	Change VPN subnet (e.g., 10.66.0.0/24)

🎯 Conclusion

Redirecting the default gateway in OpenVPN static key mode does not inherently cause disconnections —
the real problem is when the control channel gets routed into the VPN tunnel.

The solution is simple:

route remote_host 255.255.255.255 net_gateway
route 0.0.0.0 0.0.0.0 10.40.0.1

With proper NAT and IP forwarding on the server,
this setup provides a stable full-tunnel VPN that works flawlessly —
even for laptops switching between different networks.

📘 Further Reading