[Openswan Users] IPSec net to net tunnel established with RV042, but ping from one side gives Destination Host Unreachable

Mon Sep 26 04:20:58 EDT 2011

Hi All,

I'm posting regarding an issue I've been having getting an IPSec
tunnel to work. The tunnel terminates at an RV042 VPN Router device
and an OpenSwan VPN Server named "neo". This is my first foray into
OpenSwan, but I have setup net to net tunnels between two RV042
devices before.

The VPN setup is as such:

000 "Test": 172.16.0.0/24===NEO_IP<NEO_IP>[+S=C]---NEO_NEXTHOP...RV042_NEXTHOP---RV042_IP<RV042_IP>[+S=C]===192.168.1.0/24
000 "Test":     myip=172.16.0.1; hisip=192.168.1.1;
000 "Test":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0
000 "Test":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEv2ALLOW+lKOD+rKOD;
prio: 24,24; interface: eth0;
000 "Test":   newest ISAKMP SA: #0; newest IPsec SA: #0;

Neo's LAN IP is 172.16.0.1, and the RV042's LAN IP is 192.168.1.1

After the tunnel is established, I begin testing using pings. I can
ping from any device behind the RV042 to any device behind Neo, I can
even ping from the RV042 itself to Neo using diagnostic tools. Neo is
able to give back an ICMP response through the tunnel. Additionally, I
was able to setup an apache webserver on a server sitting in Neo's LAN
and visit that from the RV042's LAN using the IP 172.16.0.2.

However, when I try and ping from Neo, or a server in Neo's LAN, to
any IP in the RV042's LAN, I get "From X.X.X.X icmp_seq=2 Destination
Host Unreachable". Where X.X.X.X seems to be some hop involved when
trying to trace to the LAN IP over the internet. For example, trying
to ping 192.168.1.1 from Neo while SSHd in from home, I get:

>From 203.206.233.73 icmp_seq=2 Destination Host Unreachable

If I run "mtr 192.168.1.1" from Neo, the last hop before the trace
dies is also 203.206.233.73, so it seems like Neo is trying to send
out the ICMP packets out over the internet, instead of the IPSec
tunnel, when it is the one initiating a connection. It is still able
to send response traffic through the tunnel OK, hence why I am able to
get an ICMP response from it when starting a ping from behind the
RV042.

* The nexthop values have been specified in the conn definition. I've
determined them by doing a trace from both LANs to the public IP on
the other side, I am assuming this is OK?
* The RV042 is running the latest firmare, 1.3.13.02-tm
* Neo is running Ubuntu 10.04 with Linux Openswan
U2.6.23/K2.6.32-28-generic-pae (netkey)
* Neo's traffic passes through a Linux bridge before connecting to the
internet, this allows me to see the traffic after it leaves Neo.

I have done packet captures with tcpdump and have compared successful
pings from the RV042 to Neo, with the unsuccessful pings from Neo to
the RV042:

- Successful pings have a length of 116 bytes, and are encrypted, they
contain ESP(spi=HEX,seq=HEX)
- Successful pings have destination addresses of the public IPs for
each end point.
- Unsuccessful pings have a length of 64 bytes and are identified as
ICMP packets. There is no mention of ESP.
- Unsuccessful pings have a destination address of 192.168.1.x
- Keep in mind that these same characteristics are also shown in
traffic on the Linux bridge after having left Neo. As I understand it,
Netkey can cause some confusion as to if packets are already encrypted
etc. But surely, if the traffic has already left the OpenSwan box,
there should be no doubt that the traffic should be encrypted by this
stage.

Here's my ipsec verify output on Neo:

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                             	[OK]
Linux Openswan U2.6.23/K2.6.32-28-generic-pae (netkey)
Checking for IPsec support in kernel                        	[OK]
NETKEY detected, testing for disabled ICMP send_redirects   	[OK]
NETKEY detected, testing for disabled ICMP accept_redirects 	[OK]
Checking for RSA private key (/etc/ipsec.secrets)           	[OK]
Checking that pluto is running                              	[OK]
Pluto listening for IKE on udp 500                          	[OK]
Pluto listening for NAT-T on udp 4500                       	[OK]
Two or more interfaces found, checking IP forwarding        	[OK]
Checking NAT and MASQUERADEing
Checking for 'ip' command                                   	[OK]
Checking for 'iptables' command                             	[OK]
Opportunistic Encryption Support                            	[DISABLED]

On the RV042, access rules have been configured to allow all traffic
from Neo's public IP.

Here's the firewall rules on the Linux bridge (Neo itself has been set
to accept all traffic):

ACCEPT     udp  --  0.0.0.0/0            NEO_IP      udp dpt:500
ACCEPT     udp  --  0.0.0.0/0            NEO_IP      udp dpt:4500
ACCEPT     50   --  0.0.0.0/0            NEO_IP
ACCEPT     all  --  NEO_IP       0.0.0.0/0

And finally, here's my ipsec.conf:

version	2.0	# conforms to second version of ipsec.conf specification

# basic configuration
config setup
	# Do not set debug options to debug configuration issues!
	# plutodebug / klipsdebug = "all", "none" or a combation from below:
	# "raw crypt parsing emitting control klips pfkey natt x509 dpd private"
	# eg:
	# plutodebug="control parsing"
	#
	# enable to get logs per-peer
	# plutoopts="--perpeerlog"
	#
	# Again: only enable plutodebug or klipsdebug when asked by a developer
	#
	# NAT-TRAVERSAL support, see README.NAT-Traversal
	nat_traversal=yes
	# exclude networks used on server side by adding %v4:!a.b.c.0/24
	virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!172.16.0.0/24
	# OE is now off by default. Uncomment and change to on, to enable.
	oe=off
	# which IPsec stack to use. netkey,klips,mast,auto or none
	protostack=netkey

# Add connections here

# sample VPN connection
# for more examples, see /etc/ipsec.d/examples/
conn Test
		# Left security gateway, subnet behind it, nexthop toward right.
		left=NEO_IP
		leftsubnet=172.16.0.0/24
		leftnexthop=NEO_NEXTHOP
		leftsourceip=172.16.0.1
		# Right security gateway, subnet behind it, nexthop toward left.
		right=RV042_IP
		rightsubnet=192.168.1.0/24
		rightnexthop=RV042_NEXTHOP
		rightsourceip=192.168.1.1
		# Use a tunnel connection. Transport should only really be used for IPSec-L2TP
		type=tunnel
		# To authorize this connection, but not actually start it,
		# at startup, uncomment this.
		auto=start
		# PFS prevents previous key exchanges from being broken, even if the
current one is.
		pfs=yes
		# Re-negotiate a new key/connection when the key for the current
session expires
		rekey=yes
		# Use PSK entry
		authby=secret

So it seems to me that Netkey on Neo needs to be convinced to send out
its initial connections over the VPN tunnel. But I've run out of ways
to convince it to do that. Please help!

Thanks in Advance.