Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

Office 1 (server):

  • local network: 192.168.178.0/24
  • openvpn server public ip: 192.168.178.2 on br0
  • openvpn server internal ip: 192.168.0.1 on tun0

Office 2 (client):

  • local network: 192.168.177.0/24
  • openvpn client public ip: 192.168.177.2 on p2p1
  • openvpn client internal ip: 192.168.0.6 on tun0

  • openvpn internal network: 192.168.0.0/24

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

ping 192.168.178.2

from the VPN endpoint 192.168.177.2, 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. 192.168.178.3.

11:11:28.104640 IP 192.168.0.6 > 192.168.178.3: 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 192.168.178.3 -I 192.168.177.2

Now, the output of tcpdump is ok, too:

11:20:08.266271 IP 192.168.177.2 > 192.168.178.3: ICMP echo request, id 7883, seq 17, length 64 11:20:08.316037 IP 192.168.178.3 > 192.168.177.2: 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 192.168.177.1 dev p2p1 
192.168.0.1 via 192.168.0.5 dev tun0 
192.168.0.5 dev tun0  proto kernel  scope link  src 192.168.0.6 
192.168.177.0/24 dev p2p1  proto kernel  scope link  src 192.168.177.2 
192.168.178.0/24 via 192.168.0.5 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:

local 192.168.178.2
server 192.168.0.0 255.255.255.0
proto tcp-server
port 1194
dev tun
mssfix
user nobody
group nogroup

keepalive 20 120
ping-timer-rem
persist-tun
persist-key
float
comp-lzo
push "comp-lzo"

push "route 192.168.178.0 255.255.255.0"
route 192.168.177.0 255.255.255.0
client-config-dir client-configs

There is one client config, that looks like that:

iroute  192.168.177.0 255.255.255.0
push    "route 192.168.178.0 255.255.255.0 vpn_gateway"

Client at Office 2:

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


comp-lzo
user nobody
group nogroup

persist-tun
persist-key

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

share|improve this question

1 Answer 1

up vote 2 down vote accepted

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 192.168.178.10 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 192.168.0.6. 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 192.168.0.0/24 (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.

share|improve this answer
    
Do this, he's right! This is a similar issue I had when setting up OpenVPN. –  jski Jul 23 '14 at 15:12

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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