I'm fighting with an openVPN setup for connecting two sites. This is what the scenario looks like

Office 1 (server):

  • local network:
  • openvpn server public ip: on br0
  • openvpn server internal ip: on tun0

Office 2 (client):

  • local network:
  • openvpn client public ip: on p2p1
  • openvpn client internal ip: on tun0

  • openvpn internal network:

Both, the client and the server are behind NAT routers with dynamically assigned IP adresses.

Basically, the involved machines in either office are supposed to "see" each other. After setting up the tunnel and properly configuring the routing tables at both sites, regular hosts on both networks can ping everything on those two networks. Good so far.

However, the endpoints can only see each other, but none of the hosts on their respective far end network. For instance if do a


from the VPN endpoint, it works just fine, any other address won't work; the hosts will not reply.

Now have a look at the output of tcpdump, when I ping another address, e.g.

11:11:28.104640 IP > ICMP echo request, id 2130, seq 1, length 64

The source IP does not seem quite right. It belongs to OpenVPN's internal net and I get no ICMP reply.

Things start to work when I explicitly instruct ping to use the proper source IP:

ping -I

Now, the output of tcpdump is ok, too:

11:20:08.266271 IP > ICMP echo request, id 7883, seq 17, length 64 11:20:08.316037 IP > ICMP echo reply, id 7883, seq 17, length 64

Looking at the critical entry in the client's routing table it's kinda obvious that the source address is from the internal network:

default via dev p2p1 via dev tun0 dev tun0  proto kernel  scope link  src dev p2p1  proto kernel  scope link  src via dev tun0

Is there a possibility to make OpenVPN create that entry with an appropriate src ??

Here are my openVPN config files. I'll skip the TLS parts, since the tunnel itself works as expected.

Server at office 1:

proto tcp-server
port 1194
dev tun
user nobody
group nogroup

keepalive 20 120
push "comp-lzo"

push "route"
client-config-dir client-configs

There is one client config, that looks like that:

push    "route vpn_gateway"

Client at Office 2:

dev tun0
remote <server address>
proto tcp-client
port 1194
connect-retry 15

user nobody
group nogroup


I'm really at a loss here... your help is very much appreciated.

1 Answer 1


The behaviour you're seeing is by design. A host on a network will by default use the IP address of the interface where the traffic is exiting as the source IP.

A client machine on one of the LANs will use for example as its source IP because it's not multihomed. The gateway will then route the packet to your OpenVPN box and it will pass over the tunnel with no problems.

However, if you're going from the OpenVPN box itself, it will use the IP address of the OpenVPN interface since that's where the packet would exit.

Which is fine. It reaches the remote site. But then the remote site wants to send packets for the ping response to The response goes to the gateway, but since the gateway (I'm assuming, since you didn't post the routing tables of the gateway on the network) doesn't have a route for that network, it doesn't know how to proceed.

The easiest way to solve this would be simply to add a route for (your OpenVPN network) to the gateways of both networks.

Another option, if your operating system supports it (you didn't specify what OS you're running OpenVPN on) would be to see if you can use the "src" parameter of a route to override this default behavior of chosing the IP address of the egress interface. Please refer to the question titled How to set a custom route source in openvpn for more information.

  • Do this, he's right! This is a similar issue I had when setting up OpenVPN.
    – jski
    Commented Jul 23, 2014 at 15:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .