Routing Traffic Coming to OpenVPN Access Server to the VPN Not Working

Routing traffic to an OpenVPN Access Server often fails because the server’s default route is overwritten by the VPN tunnel, causing return traffic to loop or drop. This article explains how to fix asymmetric routing and split tunneling issues on Ubuntu by adjusting kernel parameters and firewall rules.

Understanding the Routing Conflict

When you connect to an OpenVPN Access Server, the client typically pushes a default route (0.0.0.0/0) to the operating system. On many Linux systems, including Ubuntu, this causes the kernel to send all outbound internet traffic through the VPN interface. However, the problem described in the title refers to incoming traffic or traffic destined for the server itself that gets lost. This usually happens due to two primary mechanisms: 1. Asymmetric Routing: The packet arrives via one interface but tries to leave via another, causing the firewall to drop it. 2. Policy Routing Conflicts: The OpenVPN daemon may modify the main routing table, interfering with local services like SSH or web servers hosted on the same machine. If your server cannot receive packets from the VPN network, or if clients cannot reach other services behind the server, the routing table is likely misconfigured. You must ensure that traffic destined for the LAN remains on the LAN interface while traffic for the public internet goes through the tunnel. Routing Traffic: Static IP vs. DHCP on Ubuntu 22.04 provides essential context for understanding how Ubuntu handles interface-specific routes, which is critical when debugging these conflicts.

Verifying the Kernel Forwarding Settings

Before modifying complex routing tables, ensure that the Linux kernel is actually allowed to forward packets between interfaces. If IP forwarding is disabled, no amount of routing configuration will work. Check the current status by running:

sysctl net.ipv4.ip_forward

If the output is net.ipv4.ip_forward = 0, forwarding is disabled. Enable it immediately with:

sudo sysctl -w net.ipv4.ip_forward=1

To make this change persistent across reboots, edit the /etc/sysctl.conf file or create a new file in /etc/sysctl.d/. Add the following line:

net.ipv4.ip_forward = 1

Apply the changes using sudo sysctl --system. Without this setting, the server acts as a dead end rather than a router, dropping any packet that needs to traverse from the VPN subnet to the physical network.

Configuring Split Tunneling Correctly

The most common cause of routing failures is pushing a default route to clients who do not need all their traffic tunneled. If you only want VPN clients to access specific internal resources, you should avoid pushing redirect-gateway def1 unless absolutely necessary. In the OpenVPN Access Server admin panel (usually accessible at https://your-server-ip:943/admin), navigate to the Network settings. Look for the option labeled Split Tunneling. Ensure that "Push Default Route" is unchecked if you want clients to keep their local internet connection active. Instead, define specific subnets that should be routed through the VPN. For example, if your internal network is 192.168.1.0/24, add this subnet to the push routes list. This prevents the client's OS from overwriting its own default gateway, which resolves the issue where clients can ping the server but cannot access external websites, or vice versa.

Adjusting Firewall Rules and NAT

Even with correct routing, the firewall may block traffic. OpenVPN Access Server uses iptables or nftables to manage Network Address Translation (NAT). If NAT is not configured correctly, packets leaving the VPN will have private source IPs that are unroutable on the public internet. Verify that the MASQUERADE rule exists for the VPN interface (typically tun0). Run:

sudo iptables -t nat -L -n -v

Look for a chain named POSTROUTING with a rule that matches the VPN subnet and targets MASQUERADE. If this is missing, traffic from VPN clients will fail to reach external networks. If you are managing the firewall manually, ensure that INPUT rules allow traffic from the VPN subnet to reach local services. A common mistake is having a DROP rule for non-LAN traffic that inadvertently blocks VPN connections. Setting up a NAT Server in Hetzner Cloud: Step-by-Step Guide offers valuable insights into NAT configurations that apply similarly to OpenVPN setups, particularly regarding masquerading and port forwarding.

Diagnosing Persistent Issues

If traffic still does not flow correctly, use tcpdump to trace the packets. Capture traffic on both the physical interface (e.g., eth0) and the VPN interface (tun0):

sudo tcpdump -i eth0 -nn -v

sudo tcpdump -i tun0 -nn -v

Compare the outputs. If you see packets arriving on tun0 but never appearing on eth0, the routing table is failing to direct them. Check the output of ip route show to ensure there is a valid path for the destination subnet. Conversely, if packets appear on eth0 but not on tun0, the issue lies with incoming routing policies. Ensure that reverse path filtering (rp_filter) is set to loose mode (2) or disabled (0) if you are performing asymmetric routing checks.

sysctl net.ipv4.conf.all.rp_filter

By systematically verifying forwarding, routing tables, and NAT rules, you can resolve the majority of OpenVPN Access Server connectivity issues.

Frequently Asked Questions

Why can I ping the OpenVPN server but not access the internet?

This indicates that local routing works, but outbound NAT or default routing is misconfigured. Ensure that the MASQUERADE rule in iptables covers the VPN subnet and that you are not pushing a default route that conflicts with your client's existing gateway.

How do I disable split tunneling completely?

To force all traffic through the VPN, enable "Push Default Route" in the OpenVPN Access Server admin panel under Network settings. This sends 0.0.0.0/0 to clients, overriding their local gateway for all traffic.

What causes "Permission Denied" errors when starting OpenVPN?

This is often related to SELinux or AppArmor profiles blocking access to the tap/tun devices. Check your system logs with journalctl -u openvpn to identify specific policy denials and adjust the security contexts accordingly.

Can I use OpenVPN Access Server without root privileges?

No, OpenVPN requires root access to configure network interfaces, modify routing tables, and manage firewall rules. Running it as a standard user will result in immediate failure to bind sockets or create tunnels.

How do I verify if IP forwarding is enabled after a reboot?

Run sysctl net.ipv4.ip_forward immediately after booting. If it returns 0, your persistence configuration in /etc/sysctl.conf was not applied correctly, or a startup script is resetting the value.