[Openswan Users] Routing problem and pluto crash
Gwyn Connor
gwyn.connor at googlemail.com
Mon Apr 6 16:26:59 EDT 2009
Hi,
I am trying to create a site-to-site VPN tunnel using Openswan. I configured
everything and the tunnel is established just fine. However, my test PING
didn't work. The ICMP packets are sent properly, tcpdump and ip xfrm monitor
show that on both sides. But the replies are not sent back. It almost looks
like the "out" routing policy is missing on that host.
Here's my configuration:
HOST1 (Openswan 2.6.16 with NETKEY, Kernel 2.6.27.7):
conn testvpn
type=tunnel
left=%defaultroute
leftsubnet=10.0.1.0/24
leftsourceip=10.0.1.1
leftcert=/etc/ipsec.d/certs/testvpn.crt
leftid="C=DE, ST=BW, O=test, CN=test VPN, E=vpn at example.org"
right=%any
rightsubnet=10.0.2.0/24
rightsourceip=10.0.2.1
rightrsasigkey=%cert
rightid="C=DE, ST=BW, O=test, CN=*, E=*"
auto=add
HOST2 (Openswan 2.4.7 with NETKEY, Kernel 2.6.27.19):
conn testvpn
type=tunnel
left=129.13.72.2
leftsubnet=10.0.2.0/24
leftsourceip=10.0.2.1
leftcert=/etc/ipsec.d/certs/server-test.crt
right=141.3.151.44
rightsubnet=10.0.1.0/24
rightsourceip=10.0.1.1
rightid="C=DE, ST=BW, O=test, CN=test VPN, E=vpn at example.org"
auto=start
According to the log on HOST1, the connection is established:
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
ignoring unknown Vendor ID payload [4f455a7e4261425d725c705f]
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [Dead Peer Detection]
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [RFC 3947] method set to=109
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
but already using method 109
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
but already using method 109
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
but already using method 109
Apr 5 22:14:23 backup pluto[28388]: packet from 129.13.72.2:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
responding to Main Mode from unknown peer 129.13.72.2
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
NAT-Traversal: Result using RFC 3947 (NAT-Traversal): no NAT detected
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1: Main
mode peer ID is ID_DER_ASN1_DN: 'C=DE, ST=BW, O=test, CN=Server test,
E=vpn at example.org'
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1: no
crl from issuer "C=DE, ST=BW, L=KA, O=test, CN=test Root CA,
E=certs at example.org" found (strict=no)
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1: I am
sending my cert
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1536}
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #1: the
peer proposed: 10.0.1.0/24:0/0 -> 10.0.2.0/24:0/0
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
responding to Quick Mode proposal {msgid:89b76f66}
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
us: 10.0.1.0/24===141.3.151.44[C=DE, ST=BW, O=test, CN=test VPN,
E=vpn at example.org]
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
them: 129.13.72.2[C=DE, ST=BW, O=test, CN=Server test,
E=vpn at example.org]===10.0.2.0/24
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Apr 5 22:14:23 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Apr 5 22:14:24 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Apr 5 22:14:24 backup pluto[28388]: "testvpn"[1] 129.13.72.2 #2:
STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xfe9c919d
<0xf909a4b3 xfrm=AES_0-HMAC_SHA1 NATOA=<invalid> NATD=<invalid>:500
DPD=enabled}
But HOST1 seems to have incomplete routing policies (ip xfrm policy),
it is missing an "out" policy.
src 10.0.2.0/24 dst 10.0.1.0/24
dir in priority 2344 ptype main
tmpl src 129.13.72.2 dst 141.3.151.44
proto esp reqid 16389 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
dir fwd priority 2344 ptype main
tmpl src 129.13.72.2 dst 141.3.151.44
proto esp reqid 16389 mode tunnel
On HOST2 everything looks fine:
src 10.0.1.0/24 dst 10.0.2.0/24
dir in priority 2344 ptype main
tmpl src 141.3.151.44 dst 129.13.72.2
proto esp reqid 16385 mode tunnel
src 10.0.1.0/24 dst 10.0.2.0/24
dir fwd priority 2344 ptype main
tmpl src 141.3.151.44 dst 129.13.72.2
proto esp reqid 16385 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
dir out priority 2344 ptype main
tmpl src 129.13.72.2 dst 141.3.151.44
proto esp reqid 16385 mode tunnel
I also analyzed the packet flow with "ip xfrm monitor" on both hosts for a
single ICMP packet originating from HOST2:
# ping -c 1 10.0.1.1
HOST2 (where the PING originated from):
Async event (0x20) timer expired
src 129.13.72.2 dst 141.3.151.44 reqid 0x4001 protocol esp
SPI 0xf909a4b3
HOST1 (where the PING went to):
Async event (0x20) timer expired
src 129.13.72.2 dst 141.3.151.44 reqid 0x4005 protocol esp
SPI 0xf909a4b3
Async event (0x20) timer expired
src 141.3.151.44 dst 129.13.72.2 reqid 0x4005 protocol esp
SPI 0xfe9c919d
Could all this be related to right=%any in my configuration on HOST1?
I also tried setting the actual IP address there, but this made pluto
crash due to an ASSERTION failure:
Apr 5 23:18:08 backup pluto[31127]: "testvpn" #2: responding to Quick
Mode proposal {msgid:a949675c}
Apr 5 23:18:08 backup pluto[31127]: "testvpn" #2: us:
10.0.1.0/24===141.3.151.44[C=DE, ST=BW, O=test AG, CN=test VPN,
E=vpn at example.org]
Apr 5 23:18:08 backup pluto[31127]: "testvpn" #2: them:
129.13.72.2<129.13.72.2>[C=DE, ST=BW, O=test, CN=Server test,
E=vpn at example.org]===10.0.2.0/24
Apr 5 23:18:09 backup pluto[31127]: "testvpn" #2: ASSERTION FAILED at
/usr/src/packages/BUILD/openswan-2.6.16/programs/pluto/kernel.c:2157:
c->kind == CK_PERMANENT || c->kind == CK_INSTANCE
Any ideas how I can fix it to make the VPN work?
Best regards
Gwyn
More information about the Users
mailing list