[Openswan Users]

Thu Apr 6 18:12:58 CEST 2006

On Thu, 6 Apr 2006, Brian Candler 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?

> 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 ?

> Anyway, at the Openswan/Openwrt side, I have in /etc/ipsec.conf:
>
>     version 2.0
>
>     config setup
>             nat_traversal=yes
>
>     conn L2TP
>             authby=secret

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.

>     root at OpenWrt:~# ipsec auto --verbose --up L2TP

>     004 "L2TP" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x1a6ea42b <0x29281815 xfrm=3DES_0-HMAC_SHA1 NATD=Y.Y.Y.Y:4500 DPD=none}

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.

> When I've seen this message in the past, it's been to do with the proto/port
> not matching the one in the SA. The SA itself seems to be OK though: during
> the quick mode negotiation, the Cisco logs the following
>
>     Apr  6 14:20:37 devlns1-1 48624: Apr  6 13:20:37.203: IPSEC(initialize_sas): ,
>     Apr  6 14:20:37 devlns1-1 48625:   (key eng. msg.) INBOUND local= Y.Y.Y.Y, remote= X.X.X.X,
>     Apr  6 14:20:37 devlns1-1 48626:     local_proxy= Y.Y.Y.Y/0.0.0.0/17/1701 (type=1),
>     Apr  6 14:20:37 devlns1-1 48627:     remote_proxy= X.X.X.X/0.0.0.0/17/1701 (type=1)
>     Apr  6 14:20:37 devlns1-1 48628: ,
>     Apr  6 14:20:37 devlns1-1 48629:     protocol= ESP, transform= esp-3des esp-sha-hmac  (Transport-UDP),
>     Apr  6 14:20:37 devlns1-1 48630:     lifedur= 28800s and 0kb,
>     Apr  6 14:20:37 devlns1-1 48631:     spi= 0x1A6EA42B(443458603), conn_id= 0, keysize= 0, flags= 0x800
>     Apr  6 14:20:37 devlns1-1 48632: Apr  6 13:20:37.203: IPSEC(initialize_sas): ,
>     Apr  6 14:20:37 devlns1-1 48633:   (key eng. msg.) OUTBOUND local= Y.Y.Y.Y, remote= X.X.X.X,
>     Apr  6 14:20:37 devlns1-1 48634:     local_proxy= Y.Y.Y.Y/0.0.0.0/17/1701 (type=1),
>     Apr  6 14:20:37 devlns1-1 48635:     remote_proxy= X.X.X.X/0.0.0.0/17/1701 (type=1),
>     Apr  6 14:20:37 devlns1-1 48636:     protocol= ESP, transform= esp-3des esp-sha-hmac  (Transport-UDP),
>     Apr  6 14:20:37 devlns1-1 48637:     lifedur= 28800s and 0kb,
>     Apr  6 14:20:37 devlns1-1 48638:     spi= 0x29281815(690493461), conn_id= 0, keysize= 0, flags= 0x808
>     Apr  6 14:20:37 devlns1-1 48639: Apr  6 13:20:37.203: Crypto mapdb : proxy_match
>     Apr  6 14:20:37 devlns1-1 48640:        src addr     : Y.Y.Y.Y
>     Apr  6 14:20:37 devlns1-1 48641:        dst addr     : X.X.X.X
>     Apr  6 14:20:37 devlns1-1 48642:        protocol     : 17
>     Apr  6 14:20:37 devlns1-1 48643:        src port     : 1701
>     Apr  6 14:20:37 devlns1-1 48644:        dst port     : 1701
>
> and dumping the SA looks OK too:
>
> [Cisco side]
>
>     devlns1-1#sh crypto ipsec sa
>
>     interface: GigabitEthernet0/0.10
>         Crypto map tag: CRYP_MAP, local addr Y.Y.Y.Y
>
>        protected vrf: (none)
>        local  ident (addr/mask/prot/port): (Y.Y.Y.Y/255.255.255.255/17/1701)
>        remote ident (addr/mask/prot/port): (X.X.X.X/255.255.255.255/17/63247)
>        current_peer X.X.X.X port 63247
>          PERMIT, flags={}
>         #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
>         #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
>         #pkts compressed: 0, #pkts decompressed: 0
>         #pkts not compressed: 0, #pkts compr. failed: 0
>         #pkts not decompressed: 0, #pkts decompress failed: 0
>         #send errors 0, #recv errors 40
>        Translating: Inside Remote Port 63247 Outside Remote Port 1701
>
>          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?

> When I start sending L2TP packets, tcpdump on a hub upstream of the openswan
> box shows:
>
> 14:40:37.016133 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 29) 10.71.32.1.4500 > Y.Y.Y.Y.4500: isakmp-nat-keep-alive
> 14:40:51.868535 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: UDP (17), length: 168) 10.71.32.1.4500 > Y.Y.Y.Y.4500: UDP-encap: ESP(spi=0x1a6ea42b,seq=0x29), length 140

looks okay.

> * 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.

> This is very weird; there's nothing wrong with that declaration. So I
> juggled the lines in /etc/ipsec.conf around, and it went away. I then
> juggled them back again, and it stayed away :-( Ooerr. Maybe something odd
> is going on with my shell or with awk.

Could be, that is weird.

> * I tried changing to
>
>         leftprotoport=17/0
>
> and restarting the SAs, but this doesn't make a difference; the decrypted
> packets are still rejected with the same error (although the Cisco correctly
> shows 17/0 instead of 17/1701)

Since the SA gets established, there should not be a problem with these. They
have been agreed.

> Anybody got any ideas what's going on here?
>
> I notice there have been a number of NAT-T related changed since 2.4.4 in
> the source, in particular for NAT-T with transport mode (e.g. new compiler
> defines such as I_KNOW_TRANSPORT_MODE_HAS_SECURITY_CONCERN_BUT_I_WANT_IT).
> However I see that Makefile.inc has
>
>     USE_NAT_TRAVERSAL?=true
>     USE_NAT_TRAVERSAL_TRANSPORT_MODE?=true
>
> and I think these should set those defines.

It should, yes.

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

Paul