[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