OpenVPN: How to reach a specific ip on client network side?

To reach a specific IP on the client network side using standard OpenVPN, you must configure static routes on both the server and client. The server needs to know how to return traffic to the client’s subnet, while the client must be instructed to route traffic destined for that specific IP through the VPN tunnel. This ensures bidirectional connectivity between the two networks.

Understanding the Routing Challenge

By default, OpenVPN pushes routes from the server to the client, allowing the client to access resources on the server's network. However, reverse communication is not automatic. If you want the server (or other clients connected to the server) to initiate a connection to a device with a specific IP address on the client’s local network, the server must have a route pointing back to that client’s subnet via the VPN interface. Simultaneously, the client machine itself must be configured to send packets destined for that specific IP into the tunnel rather than out its default gateway. Without these explicit routing configurations, packets will either be dropped or routed incorrectly, resulting in unreachable hosts.

Configuring Server-Side Static Routes

The first step involves modifying the OpenVPN server configuration file, typically located at /etc/openvpn/server.conf. You need to add a route directive that tells the OpenVPN server how to reach the client’s internal network. This directive requires the target network address, the subnet mask, and the name of the virtual tunnel interface (usually tun0). For example, if the client’s local network is 192.168.50.0/24, you would add the following line to the server configuration:

route 192.168.50.0 255.255.255.0 tun0

This command instructs the server to send any traffic intended for the 192.168.50.0 network through the tun0 interface. After adding this line, you must restart the OpenVPN service to apply the changes. It is crucial to ensure that the server’s underlying operating system also has a valid route to this network. In many cases, the OpenVPN daemon handles the kernel routing table automatically when it starts, but verifying that the route exists in the main routing table is a good diagnostic step. If you are using multiple clients with different subnets, you can define multiple route directives, each targeting a different subnet. For more details on managing complex routing scenarios, see Routing Traffic Coming to OpenVPN Access Server to the VPN Not Working.

Configuring Client-Side Push Routes

While the server knows how to reach the client’s network, the client computer itself still needs to know where to send packets destined for that specific IP. By default, the client’s OS will try to reach all non-local traffic via its primary network interface (e.g., Wi-Fi or Ethernet). To force traffic for the specific IP through the VPN, you can use the push directive on the server side. This sends configuration instructions to the client upon connection. In the server configuration file (/etc/openvpn/server.conf), add a push command for the specific IP or subnet. If you only want to route one specific IP, such as 192.168.50.100, you can push a /32 host route:

push "route 192.168.50.100 255.255.255.255"

If you want the client to route its entire local subnet through the VPN, you can push the subnet route instead:

push "route 192.168.50.0 255.255.255.0"

When the client connects, its OpenVPN client software will update its local routing table to include these pushed routes. This ensures that any application on the client trying to communicate with 192.168.50.100 will send the packet into the encrypted tunnel towards the server. Note that pushing routes can sometimes cause conflicts if the client already has a direct route to that subnet via another interface. In such cases, you may need to adjust the metric or use policy-based routing on the client OS.

Verifying Connectivity and Troubleshooting

Once the configurations are in place, verify the setup by checking the routing tables on both ends. On the server, use ip route show to confirm that the route to 192.168.50.0/24 points to tun0. On the client, run ip route get 192.168.50.100 to ensure the output indicates the tunnel interface. If connectivity fails, check for firewall rules that might be blocking ICMP or TCP traffic on the intermediate devices. Additionally, ensure that NAT is not interfering with the return path if the networks are behind different gateways. For advanced troubleshooting involving static routes and forwarding, refer to Static Route and Forward Traffic Between Two Interfaces.

Frequently Asked Questions

Why can I ping the server but not the client's internal IP?

This usually indicates that the server lacks a route back to the client's subnet. Ensure you have added the route directive in the server configuration pointing to the client's network via the tun0 interface.

Does pushing a route override the client's default gateway?

No, pushing a route adds a specific entry to the client's routing table. It does not change the default gateway unless you push a redirect-gateway directive, which forces all traffic through the VPN.

What if the client is behind a NAT device?

If the client is behind NAT, the server cannot initiate connections directly to the client's internal IP without additional port forwarding or hole-punching mechanisms. Standard OpenVPN routing assumes routable IPs within the tunnel context.

Can I route only one specific IP instead of the whole subnet?

Yes, you can push a /32 host route for a single IP address. Use the syntax push "route x.x.x.x 255.255.255.255" to target just that specific device.

How do I remove a pushed route if it causes issues?

You can disconnect the client and reconnect after removing the push directive from the server config. Alternatively, manually delete the route from the client's OS routing table using commands like route delete or ip route del.