To configure an OpenVPN client-to-site connection without routing all traffic through the tunnel, you must disable the default push of a default gateway on the server and manually specify only the specific subnets that should traverse the VPN. This approach ensures that general internet traffic continues to use your local network interface while internal corporate resources are securely accessed via the encrypted tunnel.
Understanding the Default Behavior
By default, when a client connects to an OpenVPN server, the server pushes a configuration directive calledredirect-gateway def1 bypass-dns. This directive forces the client's operating system to change its default route, sending all outbound internet traffic through the VPN tunnel. While this provides privacy, it often results in slower performance for non-corporate websites and can cause issues with services that require a stable local IP address. To achieve a split-tunnel or selective routing setup, we need to override this behavior by explicitly defining which networks should be routed through the virtual private network.
The Role of Pushed Routes
OpenVPN operates by pushing configuration options from the server to the connecting clients. The most critical option for routing is thepush "route" directive. When you omit the redirect-gateway command entirely, the client will not establish a default route through the VPN interface. Instead, it will maintain its existing default route pointing to its local router. You then add specific push "route" lines for every subnet that resides behind the VPN server. For example, if your office network uses the 192.168.10.0/24 subnet, you would push that specific route. The client will then add a static route to its routing table, directing packets destined for that subnet into the tun0 interface, while all other traffic follows the normal path.
For more details on troubleshooting connectivity issues within the server LAN after making these changes, see our guide on OpenVPN: Can't Connect Computers Inside the Server LAN? Troubleshooting Guide.
Configuring the OpenVPN Server
The first step involves editing the main server configuration file, typically located at/etc/openvpn/server.conf or within a specific server profile directory depending on your distribution. You must locate any existing line that contains redirect-gateway and comment it out or remove it completely. This prevents the automatic hijacking of the client's default gateway.
Next, you need to define the networks that should be accessible via the VPN. Use the push directive followed by the route keyword. The syntax is as follows:
push "route 192.168.10.0 255.255.255.0"192.168.10.0 network with a subnet mask of 255.255.255.0 should be sent through the VPN tunnel. If you have multiple subnets, such as a guest network or a database VLAN, add additional push lines for each one. Ensure that the IP addresses and masks match the actual network topology of your remote site. After making these changes, restart the OpenVPN service to apply the new configuration.
Configuring the Client
On the client side, the configuration depends on whether you are using a manual client configuration or a management tool like OpenVPN Connect. If you are using a manual.ovpn file, ensure that the file does not contain any redirect-gateway directives. Most modern client configurations inherit these settings from the server push, so removing it from the server is usually sufficient. However, if your client configuration file explicitly includes redirect-gateway, you must remove or comment out that line to prevent local overrides.
You may also need to adjust DNS settings. By default, some setups push DNS servers located inside the VPN. If you want to keep using your local ISP's DNS for general browsing but resolve internal names via the VPN, you can push specific DNS servers for internal domains or use split-DNS configurations. For standard setups where you simply want internet traffic to remain local, leaving DNS settings unmodified or pushing your local DNS server is often the best approach.
If you encounter issues where applications fail to connect despite the VPN being active, check our article on Program won't connect through OpenVPN to diagnose potential firewall or binding issues.
Verifying Routing Tables
Once connected, verify that the routing is working as intended. On Linux or macOS, use theip route or netstat -rn command. You should see your default route still pointing to your local gateway (e.g., default via 192.168.1.1 dev eth0). Additionally, you should see specific routes for the pushed subnets pointing to the VPN interface (e.g., 192.168.10.0/24 dev tun0). On Windows, open the Command Prompt and run route print. Look for entries under the IPv4 Route Table that correspond to your internal subnets with the VPN adapter listed as the interface.
To test connectivity, try pinging a device on the internal network and then a public website like google.com. Both should succeed. To confirm that internet traffic is not going through the VPN, visit a "what is my IP" website. The IP address displayed should match your local public IP, not the IP address assigned by the OpenVPN provider or server.
Advanced Considerations for Traffic Management
In some complex environments, you might need to route traffic in the reverse direction or handle asymmetric routing scenarios. It is important to ensure that your firewall rules on the server allow return traffic from the VPN subnet back to the client. If you find that specific traffic is not flowing correctly, review our guide on How to Route Traffic in the Reverse Direction in VPN Tunnels for deeper insights into bidirectional flow control. Additionally, always verify that thetun interface created by OpenVPN is properly configured and not inadvertently blocking internet access due to misconfigured kernel parameters. Checking the interface status helps rule out basic connectivity failures before diving into complex routing tables. See Verify whether a tun interface (created by OpenVPN) offers access to the Internet for verification steps.
Finally, remember that while OpenVPN encrypts traffic between the client and server, the security of the exposed ports remains a concern. Understanding how your VPN port is protected against external threats is crucial for maintaining a secure remote access infrastructure. Refer to Is an Open Port for VPN Protected from Hackers? for best practices on securing your entry points.
Frequently Asked Questions
Will disabling redirect-gateway break my internet connection?
No, disablingredirect-gateway simply restores your computer's default routing behavior. Your internet traffic will continue to flow through your local router and ISP as it did before connecting to the VPN, ensuring full-speed access to global websites.
How do I add multiple subnets to the VPN route?
You can add multiple subnets by including multiplepush "route" lines in your server configuration file. Each line should specify a different network address and subnet mask corresponding to the internal networks you wish to access remotely.
Can I use this method with OpenVPN Access Server?
Yes, OpenVPN Access Server provides a web-based administration panel where you can toggle the "Redirect All Traffic" option off. This achieves the same result as manually editing the configuration files, allowing you to select specific networks for routing through the tunnel.What if I need to access a device on a subnet that isn't pushed?
If you need to access a device on a subnet that was not included in the pushed routes, you must add a newpush "route" line for that specific subnet on the server and reconnect the client. Alternatively, you can manually add a static route on the client machine, though this requires administrative privileges and persistence management.