Ok I have an OpenVPN server A which hosts the range and an OpenVPN server B that hosts Server A is also a client of server B.

This is the configuration of the tun adapters of both servers.

OpenVPN Server A

inet peer scope global tun0
inet peer scope global tun1

OpenVPN Server B

inet peer scope global tun0

Clients of OpenVPN A get all their traffic routed through Server A and out through its WAN interface. However, one IP range can only be reached through the VPN of server B. I have set up a route that passes all through the tun interface that connects server A to server B.

ip route add dev tun1

I can ping fine on server A BUT I cannot ping or reach that range when I'm on an OpenVPN client of server A. I can ping the IP of the tun address but not Can anyone shed some light into why this is happening?


I built a virtual network and a series of VMs, shown in this image, to make visualizing this problem easier.

virtual network serverfault question 720423

Each system expected to forward packets must have ipv4 forwarding enabled:

# sysctl net.ipv4.ip_forward=1

The configuration of openvpn in my test network is simplified. I'm using openvpn without authentication / encryption, running it from the command line, to provide a simple tunnel between machines "openvpn-a" and "openvpn-b".


root@openvpn-a# openvpn --remote openvpn-b --dev tun1


root@openvpn-b# openvpn --remote openvpn-a --dev tun1

I experienced the exact problem you describe, trying to ping openvpn-b ( from client-a (

This resulted from the packet getting forwarded by openvpn-a and arriving at openvpn-b with a source address for which openvpn-b did not have a route.

A solution to this problem can be approached in several ways... one, is to add a route to the 'a' side of the network on openvpn-b, via openvpn-a's tunnel device:


root@openvpn-b# ip route add via

Another is to configure openvpn-b's default route to be via openvpn-a's tunnel device:


root@openvpn-b# ip route add default via

And still another is to configure NAT on the tunnel device on openvpn-a:


root@openvpn-a# iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

Wireshark and/or tcpdump can be used to great effect when diagnosing this problem. As can be seen on openvpn-b's tunnel device when a packet arrives and there is no route to the source address network:

root@openvpn-b# tcpdump -n -i tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes
15:45:10.973251 IP > ICMP echo request, id 2550, seq 1, length 64
1 packet captured
1 packet received by filter
0 packets dropped by kernel

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.