[Openswan Users] Phase I completed,but Phase II error
Paul Wouters
paul at xelerance.com
Fri Nov 2 10:15:41 EDT 2007
On Fri, 2 Nov 2007, ??? wrote:
> The attached file is ipsec log without klipsdebug and plutodebug. It can
> work when I ping 10.2.111.2, an ipsec server ip.
> The interesting thing is If I turn on klipsdebug and plutodebug, it seems it
> cannot work because I see no any log as follows:
> "84 bytes from 10.2.111.2: icmp_seq=0 ttl=253 time=50.0 ms"
> Why?
full debug completely overloads the machine with debugging information. Especially
on embedded systems with less then 32mb ram, that can be pretty deadly.
conn net-to-net
left=%defaultroute
leftsubnet=192.168.0.0/24
leftnexthop=%defaultroute
leftcert=/etc/ipsec.d/mycert2.pem
leftrsasigkey=%cert
right=211.78.84.93
rightsubnet=10.2.111.0/24
rightid="@SSG550.sti.com.tw"
rightnexthop=%defaultroute
auto=add
pfs=no
klips_info:ipsec_init: KLIPS startup, Openswan KLIPS IPsec stack version: 2.4.9
/ $ pluto[1134]: Starting Pluto (Openswan Version 2.4.9 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OE_]{vKgCoOI)
pluto[1134]: Setting NAT-Traversal port-4500 floating to on
pluto[1134]: port floating activation criteria nat_t=1/port_fload=1
pluto[1134]: including NAT-Traversal patch (Version 0.6c)
pluto[1134]: Using KLIPS IPsec interface code on 2.4.19-rmk4
pluto[1134]: loaded host cert file '/etc/ipsec.d/mycert2.pem' (3887 bytes)
pluto[1134]: added connection description "net-to-net"
pluto[1134]: listening for IKE messages
pluto[1134]: NAT-Traversal: ESPINUDP(1) not supported by kernel for family IPv4
pluto[1134]: adding interface ipsec0/eth0 192.168.0.200:500
Your kernel seems to not have been patched for NAT-Traversal support. If one endpoint
is behind a NAT router, things will not work. And it looks like your endpoint might
be behind NAT since it is using an internal IP address.
Also, your "public ip" is part of the subnet you are negotiating. So if your tunnel
to 192.168.0.0/24 is reachable via 192.168.0.200, then how do you reach it. It might
work because it is NAT'ed, but it is not a very good design, and very fragile.
pluto[1134]: NAT-Traversal: ESPINUDP(2) not supported by kernel for family IPv4
pluto[1134]: NAT-Traversal port floating turned off
pluto[1134]: NAT-Traversal is turned OFF due to lack of KERNEL support: 0/0
pluto[1134]: "net-to-net" #1: ignoring unknown Vendor ID payload [166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000]
pluto[1134]: "net-to-net" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port floating is off
pluto[1134]: "net-to-net" #1: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
pluto[1134]: "net-to-net" #1: received Vendor ID payload [Dead Peer Detection]
pluto[1134]: "net-to-net" #1: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
003 "net-to-net" #1: ignoring unknown Vendor ID payload [166f932d55eb64d8e4df4fd37e2313f0d0fd84510000000000000000]
003 "net-to-net" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port floating is off
003 "net-to-net" #1: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
003 "net-to-net" #1: received Vendor ID payload [Dead Peer Detection]
003 "net-to-net" #1: ignoring Vendor ID payload [HeartBeat Notify 386b0100]
pluto[1134]: "net-to-net" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
pluto[1134]: "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
106 "net-to-net" #1: STATE_MAIN_I2: sent MI2, expecting MR2
pluto[1134]: "net-to-net" #1: ignoring CERT_NONE certificate request payload
pluto[1134]: "net-to-net" #1: ignoring CERT_NONE certificate request payload
pluto[1134]: "net-to-net" #1: I am sending my cert
pluto[1134]: "net-to-net" #1: I am sending a certificate request
pluto[1134]: "net-to-net" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
pluto[1134]: "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "net-to-net" #1: ignoring CERT_NONE certificate request payload
003 "net-to-net" #1: ignoring CERT_NONE certificate request payload
108 "net-to-net" #1: STATE_MAIN_I3: sent MI3, expecting MR3
pluto[1134]: "net-to-net" #1: Main mode peer ID is ID_FQDN: '@SSG550.sti.com.tw'
pluto[1134]: "net-to-net" #1: no crl from issuer "C=TW, ST=Taiwan, L=Taipei, O=Dawningtech, OU=Support, CN=Dawningtech" found (strict=no)
pluto[1134]: "net-to-net" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
pluto[1134]: "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
004 "net-to-net" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_md5 group=modp1024}
pluto[1134]: "net-to-net" #2: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+UP {using isakmp#1}
117 "net-to-net" #2: STATE_QUICK_I1: initiate
pluto[1134]: "net-to-net" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
003 "net-to-net" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
pluto[1134]: "net-to-net" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2
pluto[1134]: "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xf566fabc <0x9b6685e0 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
004 "net-to-net" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xf566fabc <0x9b6685e0 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
It looks good otherwise (though the other end sends a lot of CERT_NONE payloads for some reason.
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ipsec0
10.2.111.0 192.168.0.1 255.255.255.0 UG 0 0 0 ipsec0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
But here we see the problem. Since packets for 192.168.0.0/24 need to be tunneled, a route is
added to the ipsec device. However, that is also your "public ip", so now it screws up
routing for your "public ip". I bet if you change your subnet to 192.168.1.0/24 while
staying with your internal ip on 192.168.0.200, things will work much better.
Paul
More information about the Users
mailing list