[Openswan Users]

[Brian Candler]

On Thu, Apr 06, 2006 at 05:12:58PM +0200, Paul Wouters wrote:
> > Earlier today I started debugging a problem with 2.4.4 and L2TP over IPSEC
> > transport mode (the connection came up OK but after a while the SA stopped
> > working).
> 
> Later on you mention the machine is on private IP behind NAT. Did you apply
> a patch to make openswan behind NAT work?

I don't think so. OpenWRT applies a few minor patches to openswan, but they
seem to be tweaks to startup scripts: you can see them at

[userland]
https://dev.openwrt.org/browser/branches/whiterussian/openwrt/package/openswan/patches
[kernel]
https://dev.openwrt.org/browser/branches/whiterussian/openwrt/target/linux/package/openswan/patches

> > But then I thought I'd upgrade openswan to 2.4.5rc7 just to be up to the
> > current version; and now I'm hitting an inability to deliver packets at all
> > once the SA is established. The far end rejects each one with
> > "IPSEC(epa_des_crypt): decrypted packet failed SA identity check"
> 
> Odd. Are you sure nothing else changed? Such as the mtu ?

I'm pretty sure not. However I can't see how the MTU would affect things
here.

If I tcpdump the ipsec0 interface I can see the L2TP setup requests. If I
tcpdump the actual packets coming out of the interface I see them UDP-4500
encapsulated. The Cisco rejects them.

> Hmm, we did not do extensive testing with transport mode + PSK + NAT-T,
> because that setup is strongly discouraged. You should use X.509
> certificates instead of PSK, especially when using NAT-T.
> Other then that, the conn looks fine.

OK, although I would imagine that authentication is not the issue here.

> That looks okay too.
> 
> > * However, whenever the L2TP packets are sent, encapsulated in UDP 4500,
> > they are discarded by the Cisco. The Cisco logs the following message:
> >
> >     Apr  6 14:40:53 devlns1-1 48752: Apr  6 13:40:52.122: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
> 
> My first bet would still be packet fragmentation. With transport mode, there may
> never be fragmenting.

The tcpdump shows no fragmentation. The L2TP setup packets are small.

> >          local crypto endpt.: Y.Y.Y.Y, remote crypto endpt.: X.X.X.X
> >          path mtu 1600, ip mtu 1600
> 
> 1600?
> 
> >     root at OpenWrt:~# cat /proc/net/ipsec_eroute
> >     40         10.71.32.1/32:1701 -> Y.Y.Y.Y/32:1701 => esp0x1a6ea42b at Y.Y.Y.Y:17
> 
> Can you try setting overridemtu=1400?

OK, I've stuck this under "config setup". No change though.

> > * Not sure if this is related, but when I first did "S60ipsec start" after
> > upgrading to 2.4.5rc7 I got:
> >
> >     Jan  1 00:01:05 (none) daemon.err ipsec__plutorun: ipsec_auto: fatal error in "L2TP": (/etc/ipsec.conf, line 12) unknown parameter name "leftprotoport"
> 
> First, please correct the time on the unit.

Yep I did that too after that error was logged. The OpenWRT box has no RTC
so I have to remember to rdate it after rebooting.

> I'm not sure I understand what is going wrong here :(

No... although looking at the archives I see a couple of other people
reporting problems with L2TP/IPSEC and NAT-T in 2.4.5rc7.

I've started looking at the code. One thing which confuses me is:

[programs/pluto/nat_traversal.h]
#define NAT_TRAVERSAL_IETF_00_01     1
#define NAT_TRAVERSAL_IETF_02_03     2
#define NAT_TRAVERSAL_RFC            3
#define NAT_TRAVERSAL_OSX            4

#define NAT_TRAVERSAL_NAT_BHND_ME    30
#define NAT_TRAVERSAL_NAT_BHND_PEER  31

But the first four don't match up with this:

[lib/libopenswan/constants.c]
const char *const natt_type_bitnames[] = {
  "draft-ietf-ipsec-nat-t-ike-00/01",    /* 0 */
  "draft-ietf-ipsec-nat-t-ike-02/03",
  "RFC 3947 (NAT-Traversal)",
  "3",                                   /* 3 */
  "4",   "5",   "6",   "7",
  "8",   "9",   "10",  "11",
  "12",  "13",  "14",  "15",
  "16",  "17",  "18",  "19",
  "20",  "21",  "22",  "23",
  "24",  "25",  "26",  "27",
  "28",  "29",
  "nat is behind me",
  "nat is behind peer"
};

This means the debug messages are confusing. With plutodebug="natt" I see:

Apr  6 16:33:24 OpenWrt kern.warn pluto[5786]: "L2TP" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Apr  6 16:33:24 OpenWrt kern.warn pluto[5786]: "L2TP" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)

Method 108 is VID_NATT_IETF_03 (from pluto/vendor.h), but the second message
is claiming that it's actually RFC 3947. However I think this will only
affect the display messages and nothing else.

After negotiation, though, I still see

Apr  6 16:33:24 OpenWrt kern.warn pluto[5786]: "L2TP" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed

I notice that nat_traversal_show_result has its own mapping from bitmap to
names, instead of using natt_type_bitnames.

Regards,

Brian.