[Openswan Users] IPSec net to net tunnel established with RV042, but ping from one side gives Destination Host Unreachable
the1geekman at gmail.com
Mon Sep 26 04:20:58 EDT 2011
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
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 126.96.36.199 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 188.8.131.52, 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
* 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
* 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
- Successful pings have a length of 116 bytes, and are encrypted, they
- 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
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
# 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"
# plutodebug="control parsing"
# enable to get logs per-peer
# Again: only enable plutodebug or klipsdebug when asked by a developer
# NAT-TRAVERSAL support, see README.NAT-Traversal
# exclude networks used on server side by adding %v4:!a.b.c.0/24
# OE is now off by default. Uncomment and change to on, to enable.
# which IPsec stack to use. netkey,klips,mast,auto or none
# Add connections here
# sample VPN connection
# for more examples, see /etc/ipsec.d/examples/
# Left security gateway, subnet behind it, nexthop toward right.
# Right security gateway, subnet behind it, nexthop toward left.
# Use a tunnel connection. Transport should only really be used for IPSec-L2TP
# To authorize this connection, but not actually start it,
# at startup, uncomment this.
# PFS prevents previous key exchanges from being broken, even if the
current one is.
# Re-negotiate a new key/connection when the key for the current
# Use PSK entry
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.
More information about the Users