Can't ping public endpoints when IPSec tunnel is up

Question

I'm using openswan to link two machines via IPSec. The tunnel comes online fine and I have connectivity to each endpoint via the VPN.

However, when the tunnel is up, I lose connectivity to the public endpoint IP addresses. For example, pinging site A public address 1.2.3.4 from site B public address 4.5.6.7 (and visa versa) fails.

When the tunnel is up, I noticed something curious that could explain this behavior.

#ip xfrm policy

src 1.2.3.4/32 dst 4.5.6.7/32 
    dir out priority 2080 ptype main 
    tmpl src 0.0.0.0 dst 0.0.0.0
        proto esp reqid 0 mode transport

I snipped out the reamining output as it only contains entries that make sense (the private networks connected by the tunnel).

Any ideas what I'm missing?

Answer 1

I'm not entirely familiar with the xfrm syntax, but it looks like :

• When your VPN is not up, you have a default route to the Internet, so you can ping the way you expect
• Once the VPN comes up, the XFRM rule essentially adds a policy route which sends all traffic through the tunnel to the other end. There is probably an equivalent rule on the other end which prevents the ICMP requests from actually reaching the opposite interface through the tunnel (creating a sort of loop on the IP level).

You might want to adjust your routing such that:

• your default route always points to the Internet
• you only send through the tunnel traffic originating from whatever subnets are behind the router (excluding the other router interfaces). Alternatively, you could add static routes (or policy routes) to force traffic between the two public IPs to be sent outside the tunnel.

What this boils down to is that you need to have a way to differentiate the default route as seen from the router (towards the Internet) and the default route as observed for traffic originating on a LAN subnet behind the router. They are often quite different.