When configuring OpenVPN to route all client traffic through the VPN server, many administrators encounter situations where basic connectivity tests (like ping) work while application-level traffic (HTTP requests, traceroute) fails. This typically indicates a routing configuration issue rather than a complete VPN failure.

For proper traffic routing, your OpenVPN setup needs these essential elements:

# Critical server-side directives
push "redirect-gateway autolocal"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

The working server configuration should include these security and routing parameters:

port 1194
proto udp
dev tun
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"

Ensure your client configuration matches these parameters:

client
dev tun
proto udp
remote your.vpn.server.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun

When traffic isn't routing properly, check these diagnostic commands:

# Verify routing table
ip route show

# Check DNS resolution
dig example.com

# Test raw TCP connectivity
nc -zv 8.8.8.8 443

For complex networks, you might need additional iptables rules on the server:

# NAT configuration example
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

1. MTU/MSS issues - Try adding these to your config:

tun-mtu 1500
mssfix 1450

2. DNS leakage - Verify with:

nslookup example.com

When your OpenVPN client connects but refuses to route all traffic through the tunnel, you're experiencing split tunneling behavior. The symptoms you described - ping works but HTTP traffic fails - indicate the VPN isn't becoming the default gateway.

The magic happens in your OpenVPN server config with these directives:

push "redirect-gateway autolocal"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

Let me break down why this works:

• redirect-gateway autolocal tells the client to route all traffic through VPN while preserving the original default gateway
• The DNS pushes prevent DNS leaks that could expose your real location

After connecting, verify proper routing with these terminal commands:

# Check default route
ip route show

# Confirm DNS resolution
dig +short myip.opendns.com @resolver1.opendns.com

# Test HTTP traffic routing
curl ifconfig.me

If you're still seeing leaks, add this to your client config:

route-nopull
route 0.0.0.0 0.0.0.0 vpn_gateway

This manually overrides all IPv4 routing through the VPN interface.

On your VPS, ensure proper NAT masquerading is enabled:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

And enable IP forwarding in sysctl:

echo 1 > /proc/sys/net/ipv4/ip_forward

Here's a complete working client config for privacy-focused users:

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
auth SHA256
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3