tips

OpenVPN Server Configuration: Redirect All Client Traffic Through the VPN.

This is the eighth in a series of posts, featuring Protips, tips, tricks, hacks, and secrets provided by Our Team 🙊 — We want to share our top tips for the growing and thriving Linux community out there. Because sometimes you need a little help...

yannick Coffi, Kenzo Kylo

02 Apr 2024 • 4 min read

Photo by yannick Coffi —see more @ PRINTS -/- yC

This series of posts explores useful OpenVPN server configuration options, including secure cryptographic algorithms, client-to-client communication, traffic routing, and network security.

Important: Ensure that all required options are added to and saved in your OpenVPN server configuration file, typically /etc/openvpn/server.conf. Configuration paths may vary depending on your installation.

1. Redirect All Client Internet Traffic Through the VPN

OpenVPN provides the redirect-gateway directive to route client internet traffic through the VPN tunnel rather than through the client's regular internet connection.

This configuration is commonly used when setting up a full-tunnel VPN, where internet traffic passes through the VPN server before reaching its destination.

To enable this behavior, add the following directive to your OpenVPN server configuration:

# Redirect all client internet traffic through the VPN
push "redirect-gateway def1 bypass-dhcp"

The push directive instructs OpenVPN to send the specified configuration option to connecting clients.

Configuration Breakdown

push

Instructs the OpenVPN server to send a configuration option to connected clients. The client must accept and apply the pushed option for it to take effect.

redirect-gateway

Instructs the client to route its internet traffic through the VPN tunnel, making the VPN server the gateway for external connections.

This is useful when you want client internet traffic to pass through your VPN server instead of directly through the client's local internet connection.

def1

Modifies the client's routing table to redirect traffic using two more-specific IPv4 routes rather than simply replacing the existing default route.

Typically, OpenVPN installs routes for 0.0.0.0/1 and 128.0.0.0/1. These routes take precedence over the usual IPv4 default route while allowing the original default route to remain in the routing table.

This approach also helps OpenVPN maintain connectivity to the VPN server through the client's existing connection.

bypass-dhcp

On supported clients, this option helps preserve local DHCP-related connectivity when the default gateway is redirected through the VPN.

Its precise behavior depends on the client's operating system and OpenVPN implementation. It does not guarantee that all local network traffic will bypass the VPN.

2. How Does It Work?

Without traffic redirection, a VPN client typically sends internet traffic through its regular gateway while using the VPN only to reach specific networks.

With redirect-gateway enabled, the routing behavior changes:

Without full-tunnel routing:

Client
  |
  ├── Internet traffic ──> Local ISP ──> Internet
  |
  └── VPN traffic ───────> OpenVPN Server

With full-tunnel routing:

Client
  |
  v
OpenVPN Tunnel
  |
  v
OpenVPN Server
  |
  v
Internet

The second configuration routes the client's internet traffic through the VPN server.

Consequently, external websites generally see the VPN server's public IP address rather than the client's original public IP address, provided the server's routing, NAT, and egress configuration are correct.

Important: Server-Side Configuration

Pushing redirect-gateway is not sufficient by itself to guarantee internet connectivity through the VPN.

The OpenVPN server must also be configured to forward client traffic and provide a working route to the internet.

Depending on your network architecture, this may require:

Enabling IPv4 forwarding.
Configuring appropriate firewall forwarding rules.
Setting up source NAT or masquerading when required.
Ensuring the server has a working internet connection.
Configuring DNS resolution for VPN clients.

For example, on a Linux server, check IPv4 forwarding with:

sysctl net.ipv4.ip_forward

An output of net.ipv4.ip_forward = 1 indicates that IPv4 forwarding is enabled.

If forwarding is disabled, the server may be unable to route client traffic between the VPN interface and its external network interface.

Security consideration: Full-tunnel routing directs traffic through your VPN server, but encryption alone does not guarantee anonymity or prevent every form of traffic leakage. DNS configuration, IPv6 routing, firewall rules, and the VPN server's own security also matter.

3. Apply the Configuration

After adding the directive to your server configuration, save the file and restart the appropriate OpenVPN service.

For installations using the openvpn@server systemd unit:

sudo systemctl restart openvpn@server.service

Check the service status:

sudo systemctl status openvpn@server.service

If the service fails to start, inspect its logs:

sudo journalctl -u openvpn@server.service -n 50 --no-pager

Note: The correct service name depends on your OpenVPN installation and configuration layout.

Reconnect your VPN clients so that they receive and apply the updated routing configuration.

4. Verify Client Traffic Routing

After connecting to the VPN, verify that the client is routing internet traffic through the tunnel.

On a Linux client, inspect the IPv4 routing table:

ip -4 route

With redirect-gateway def1 applied, you will typically see routes similar to:

0.0.0.0/1 via <VPN_GATEWAY> dev tun0
128.0.0.0/1 via <VPN_GATEWAY> dev tun0

The actual gateway, interface name, and routing entries depend on your configuration.

You can also check the public IP address before and after connecting to the VPN:

curl -4 https://ifconfig.me

If the configuration is working correctly, the public IPv4 address reported while connected should generally correspond to the VPN server's internet egress address.

For a complete check, also verify DNS resolution and IPv6 routing, since IPv4 full-tunnel routing alone does not guarantee that all traffic uses the VPN.

The OpenVPN directive:

push "redirect-gateway def1 bypass-dhcp"

provides a convenient way to configure full-tunnel IPv4 routing for VPN clients.

When combined with correct server-side forwarding, firewall, NAT, and DNS configuration, it allows clients to send their internet traffic through the VPN server rather than directly through their local internet connection.

This setup is useful for centralized traffic management, protecting traffic across untrusted networks, and presenting the VPN server's public IP address to external services.

We hope this guide proves useful in configuring and securing your OpenVPN deployment.