OpenVPN: Can't Connect Computers Inside the Server LAN? Troubleshooting Guide

OpenVPN clients often fail to reach internal LAN servers because the server’s firewall blocks forwarded traffic and IP forwarding is disabled. You must enable kernel-level packet forwarding, configure your firewall (such as UFW or iptables) to allow FORWARD chain traffic on the tunnel interface, and ensure OpenVPN pushes correct routes to clients. This guide details the safe configuration steps required to establish connectivity without compromising network security.

Understanding the Connectivity Gap

When an OpenVPN client connects, it receives a virtual IP address from the VPN subnet. However, this does not automatically grant access to other subnets on the physical network where the OpenVPN server resides. The issue typically stems from two distinct layers: the operating system’s routing capabilities and the host-based firewall rules. If either layer drops packets destined for the local LAN, the connection will appear successful but result in timeouts when trying to ping or SSH into internal resources. It is crucial to understand that enabling forwarding does not mean bypassing security controls. A common mistake seen in online forums is disabling all forward policies entirely. This leaves the server vulnerable to unauthorized traffic routing. Instead, we must explicitly permit traffic only between the specific interfaces involved in the VPN handshake.

Enabling IP Forwarding at the Kernel Level

The Linux kernel must be instructed to pass packets from one network interface to another. By default, many distributions disable this behavior for security reasons. To check if it is currently enabled, run the following command:

sysctl net.ipv4.ip_forward

If the output is 0, forwarding is disabled. To enable it temporarily for testing, use:

sudo sysctl -w net.ipv4.ip_forward=1

To make this change persistent across reboots, edit the /etc/sysctl.conf file. Add or modify the following line:

net.ipv4.ip_forward = 1

Apply the changes by running sudo sysctl -p. Verify the output again to ensure it returns 1. Without this step, no amount of firewall configuration will allow traffic to traverse between the VPN tunnel and the physical LAN.

Configuring the Firewall Correctly

This section addresses the critical security aspect. Many users mistakenly run sudo ufw default allow forward, which disables the firewall’s ability to inspect and block malicious forwarded packets. This is dangerous advice that exposes your entire network. Instead, you should restrict forwarding to only the necessary interfaces. Assuming you are using ufw, you need to allow traffic specifically from the VPN interface (often named tun0) to the LAN interface (often eth0 or ens33). First, identify your interface names using ip link show. Then, apply these specific rules:

sudo ufw route allow in on tun0 out on eth0
sudo ufw route allow in on eth0 out on tun0

These commands instruct the firewall to allow traffic flowing between the tunnel and the Ethernet interface while maintaining protection against other sources. If you are using iptables directly, ensure your FORWARD chain policy is set to DROP or REJECT by default, and add explicit ACCEPT rules for the relevant subnets. For more details on securing your VPN port against external threats, see Is an Open Port for VPN Protected from Hackers?.

Verifying OpenVPN Server Configuration

Even with correct OS settings, OpenVPN itself must be configured to advertise the local network to clients. In your server.conf file, ensure you have a directive that pushes the route of your internal LAN to the connecting clients. For example, if your LAN is 192.168.1.0/24, add:

push "route 192.168.1.0 255.255.255.0"

Additionally, verify that the client-to-client directive is present if you expect clients to talk to each other, though this is less relevant for server-LAN access. Restart the OpenVPN service after making changes:

sudo systemctl restart openvpn@server

Note that the exact service name may vary depending on your installation method. Check status with systemctl status openvpn to ensure there are no errors during startup.

Testing and Troubleshooting Connectivity

Once the configuration is complete, test the connection from a connected client. Attempt to ping an internal server IP. If the ping fails, check the following:

• Client Routing: Run route print (Windows) or ip route (Linux/macOS) on the client. Ensure there is a route pointing to the VPN gateway for the internal subnet.
• Intermediate Firewalls: Ensure that any hardware firewalls or routers between the OpenVPN server and the target LAN allow traffic from the VPN subnet.
• SELinux/AppArmor: On some systems, mandatory access control frameworks may block forwarding even if UFW allows it. Check audit logs for denied operations.

If you suspect issues with how traffic is being routed through the tunnel, refer to How to Route Traffic in the Reverse Direction in VPN Tunnels for advanced troubleshooting techniques.

Ensuring Persistent and Secure Setup

After confirming connectivity, verify that the settings survive a reboot. Reboot the server and check that sysctl net.ipv4.ip_forward still returns 1 and that the UFW routes remain active. It is also wise to review your OpenVPN logs (/var/log/openvpn.log) for any warnings regarding dropped packets or authentication failures. Remember that security is an ongoing process. Regularly update your OpenVPN version and review firewall rules to ensure they align with current network requirements. Avoid generic solutions that suggest opening all ports; always follow the principle of least privilege. For guidance on creating robust remote access setups, consider reading Creating an OpenVPN Remote Access Client-to-Site VPN without Routing All Traffic.

Frequently Asked Questions

Why can I ping the OpenVPN server but not other LAN devices?

This indicates that the server itself is reachable, but it is not forwarding packets to other destinations. Ensure that net.ipv4.ip_forward` is enabled in the kernel and that your firewall allows FORWARD traffic between the tunnel interface and the LAN interface.

Does enabling IP forwarding expose my server to attacks?

Enabling forwarding alone does not expose the server, but it allows traffic to pass through. Security depends on your firewall rules. Always restrict forwarding to specific interfaces and subnets rather than allowing all traffic, as described in the firewall section above.

What if my VPN interface is not named tun0?

Interface names can vary based on the operating system and configuration. Use ip link show to identify the correct name for your VPN tunnel. Update your UFW routes and OpenVPN configurations to reflect the actual interface name used by your system.

How do I check if my firewall is blocking forwarded traffic?

You can monitor live traffic using sudo tcpdump -i tun0 and sudo tcpdump -i eth0 on the server. If you see packets arriving on the tunnel interface but none leaving the LAN interface, the firewall or routing table is likely dropping them.

Can I use OpenVPN to connect to a different subnet than the one pushed?

No, the client must have a route to the destination subnet. The server pushes the route via the push "route ..." directive. If you need access to multiple subnets, push additional route directives for each subnet you wish to reach.