[Openswan Users] HELP : fail to reconnect, but fist successfully connect

[Jacco de Leeuw]

christophe yayon wrote:

> i got the same problem with a macosx 10.5.2 client... strange, it seems
> not a iphone specific problem...

I was going to post about this later, but I might as well do it now.
First off, I don't have access to Leopard and the iPhone myself,
unfortunately.

> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: received
> Vendor ID payload [RFC 3947] method set to=109
> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> Mar 31 19:40:02 nebu pluto[22614]: "iphone"[2] XX.XX.XX.XX #5:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both
> are NATed

Something has changed in Openswan 2.4.11. VID_NATT_RFC now has a lower
priority than VID_NATT_DRAFT_IETF_IPSEC_NAT_T_IKE.
I don't know what the rationale is behind this.

> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: ignoring
> unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: ignoring
> unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: ignoring
> unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: ignoring
> unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: ignoring
> unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]

$ echo -n "draft-ietf-ipsec-nat-t-ike-08" | md5sum
8f8d83826d246b6fc7a8a6a428c11de8
$ echo -n "draft-ietf-ipsec-nat-t-ike-07" | md5sum
439b59f8ba676c4c7737ae22eab8f582
$ echo -n "draft-ietf-ipsec-nat-t-ike-06" | md5sum
4d1e0e136deafa34c4f3ea9f02ec7285
$ echo -n "draft-ietf-ipsec-nat-t-ike-05" | md5sum
80d0bb3def54565ee84645d4c85ce3ee
$ echo -n "draft-ietf-ipsec-nat-t-ike-04" | md5sum
9909b64eed937c6573de52ace952fa6b

Now this is weird. Why is Apple adding support for superseded NAT-T draft
versions to Leopard's IPsec implementation if Tiger already supports the
official RFC?

You may also notice that Vendor ID "KAME/racoon" is missing. The racoon
source code is no longer included with the network_cmds tar ball. It
looks like Apple dumped racoon because the KAME project went dormant, and
they did not want to switch to ipsec-tools.sourceforge.net.

So what is Apple using then? They are supporting these drafts, so it must
be code from somebody who was intimately involved with the NAT-T standard
track. Is anyone willing to connect with L2TP/IPsec on Leopard and then
check the output of ps and/or netstat to see what the name is of the
process listening on UDP port 500?

> Mar 31 19:40:01 nebu pluto[22614]: packet from XX.XX.XX.XX:500: received
> Vendor ID payload [Dead Peer Detection]

That's new too. It wasn't in Tiger.

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl