[Openswan Users] Missing route for an established IPSEC connection.

John Rouillard rouilj at renesys.com
Wed Feb 22 13:27:41 CET 2006


Hello all:

I am running ipsec between 4 hosts. Three of the links are
up and routing traffic but the fourth is not. The two hosts
in question are:

   dee (linux Fedora Core 2) kernel rev - 2.6.10-1.771_FC2
     running openswan-2.1.2-14.rhfc2.at

   black (linux Fedora Core 3) kernel rev - 2.6.9-1.667
     running openswan-2.1.5-2

The connection stanza's from /etc/ipsec.conf are:

dee:
  conn mht2-lah
        left=216.107.213.20
        leftsubnet=192.168.1.0/24
        leftnexthop=216.107.213.17
        leftid=@dee.renesys.com
        leftrsasigkey=[omitted 1]
        right=216.107.210.98
        rightsubnet=192.168.8.0/24
        rightnexthop=216.107.210.97
        rightid=@black.renesys.com
        rightrsasigkey=[omitted 2]
        authby=rsasig
        type=tunnel
        auto=start

black:
  conn mht2-lah
        left=216.107.213.20
        leftsubnet=192.168.1.0/24
        leftnexthop=216.107.213.17
        leftid=@dee.renesys.com
        leftrsasigkey=[omitted 1]
        right=216.107.210.98
        rightsubnet=192.168.8.0/24
        rightnexthop=216.107.210.97
        rightid=@black.renesys.com
        rightrsasigkey=[omitted 2]
        authby=rsasig
        type=tunnel
        auto=start

I can ping all of the non-vpn ip addresses above (left,
leftnexthop, right, rightnexthop) from both machines, so I
don't believe I have an underlying (physical) network
problem.

When I run "netstat -nr on dee I get:
  Kernel IP routing table
  Destination     Gateway         Genmask         Flags MSS Wind ir Iface
                                                             ow  tt
  216.107.213.16  0.0.0.0         255.255.255.248 U      0   0    0 eth0
  216.107.215.128 0.0.0.0         255.255.255.248 U      0   0    0 eth0
  216.107.210.96  216.107.213.17  255.255.255.240 UG     0   0    0 eth0
  192.168.7.0     216.107.215.129 255.255.255.0   UG     0   0    0 eth0
  192.168.3.0     0.0.0.0         255.255.255.0   U      0   0    0 eth1
  192.168.2.0     216.107.215.129 255.255.255.0   UG     0   0    0 eth0
  192.168.1.0     0.0.0.0         255.255.255.0   U      0   0    0 eth1
  192.168.0.0     216.107.215.129 255.255.255.0   UG     0   0    0 eth0
  192.168.10.0    0.0.0.0         255.255.255.0   U      0   0    0 eth0
  169.254.0.0     0.0.0.0         255.255.0.0     U      0   0    0 eth1
  0.0.0.0         216.107.215.129 0.0.0.0         UG     0   0    0 eth0

I fail to see a route for 192.168.8.0/24 which is black's
subnet. On black I do see a route for 192.168.1.0/24. The
192.168.[7,0,2].0/24 networks are also ipsec VPN links and
they are running fine.

Running "ipsec auto --route mht2-lah" on dee doesn't change
the routing table, but it does change the routing table when
run on black.

After much googling I have not had anything even close to a
similar problem description except for:

  http://lists.openswan.org/pipermail/users/2005-April/004449.html
  http://lists.openswan.org/pipermail/users/2005-April/004451.html

which describes a similar problem (based on the ipsec
--status output) that was fixed by turning off opportunistic
encryption. I added:

  include /etc/ipsec.d/examples/no_oe.conf

to the top (right under the version line) of ipsec.conf on
both dee and black and ran "ipsec setup restart" with no
change in routing tables.

I believe the link is up because "ipsec auto --status"
shows (from dee):

  000 "mht2-lah":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP;
      prio: 24,24; interface: eth0:5; 
  000 "mht2-lah":   newest ISAKMP SA: #61; newest IPsec SA:
  000 #61: "mht2-lah" STATE_MAIN_I4 (ISAKMP SA established);
      EVENT_SA_REPLACE in 1692s; newest ISAKMP
  000 #64: "mht2-lah" STATE_MAIN_R3 (sent MR3, ISAKMP SA
      established); EVENT_SA_REPLACE in 2086s
  000 #58: "mht2-lah" STATE_QUICK_I2 (sent QI2, IPsec SA
      established); EVENT_SA_REPLACE in 23187s; newest IPSEC; eroute owner
  000 #58: "mht2-lah" esp.5bf310a9 at 216.107.210.98
      esp.51b5bf16 at 216.107.213.20 tun.0 at 216.107.210.98 tun.0 at 216.107.213.20
  000 #57: "mht2-lah" STATE_QUICK_I2 (sent QI2, IPsec SA
      established); EVENT_SA_REPLACE in 23163s
  000 #57: "mht2-lah" esp.df6d5b64 at 216.107.210.98
      esp.1d1d82b3 at 216.107.213.20 tun.0 at 216.107.210.98 tun.0 at 216.107.213.20

There are more instances of the last two lines in the
report, but no more instances of the ISAKMP SA established
line. Similar output is seen on black.

I am also seeing:

  000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
  000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
  000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
  000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
  000 192.168.1.97/32:0 -17-> 192.168.8.233/32:0 => %hold 0 %acquire-netlink
  ...

Lines at the end of the status report, and the affected
addresses are all traffic that would go over the VPN link.

I have rebooted black (it was having a similar problem with
another ipsec connection to a different office) and the
original problem went away, but then this problem started.
One oddity in that prior problem was that ping was failing
with a:

   connect: Resource temporarily unavailable

I am not seeing this failure currently. Before the reboot,
this link was working fine.

I have shutdown/restarted ipsec on dee (and also on black)
multiple times with no resolution as well as trying to
start/stop the connection using ipsec auto --up and --down
and tracing through the sequence to see if it looks the same
as the other working links.

The firewall rules look fine, but they shouldn't interfere
with the routing table entry. I have even manually added a
route for the 192.168.8.0 net to mimic the entry in netstat
(and not surprisingly) it didn't make a difference.

So does anybody have any ideas?

"ipsec barf" output is available on request, but it is
pretty lengthy so I didn't want to send it on the first
email.

Thanks for your help and time in reading this email.

--
				-- rouilj

John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111


More information about the Users mailing list