[Openswan Users]

[Brian Candler]

(My apologies for the volume of noise to those who couldn't care less about
L2TP over IPSEC :-)

> So I'm still stuck in the position where I can open an L2TP/IPSEC connection
> to a Cisco IOS server using 2.4.4, but not 2.4.5 :-(

The other option available to me was to trace the decrypted packets at the
Cisco end, using both 2.4.4 and 2.4.5 as the source. This turned out to be
interesting.

With both 2.4.4 and 2.4.5, the first packet which arrived at the Cisco was
the same, and in both cases the Cisco discarded it with
"IPSEC(epa_des_crypt): decrypted packet failed SA identity check". The
packet looks like this:

45000080
00004000  >> ident=0, flags=DF
3B111C3A
XXXXXXXX
YYYYYYYY
06A506A5
006C0000
....

With 2.4.5, the second packet which arrived at the Cisco was the same as
this, and was also discarded. None got through.

With 2.4.4, the second packet which arrived at the Cisco was slightly
different:

45000080
CBF80000  >> ident=CBF8, flags=0
3B119041
XXXXXXXX
YYYYYYYY
06A506A5
006C0000
....

Apart from the checksum, the only differences are:
- the DF bit is not set
- the 'identity' field is set

In other words, the packet sent by Openswan in this case is eligible for
fragmentation. [The same DF bit and ident are visible in the packet before
decryption, too]

So questions which spring to mind are:

* Why is openswan 2.4.4 sending the second packet different from the first?
  Can I configure it to clear DF always before sending?

* Why is the Cisco rejecting (small) packets with DF set after decryption?
  Can I configure it to accept them? [1]

There is one other difference I can see in the dump: openswan 2.4.5 is
offering NAT-T draft v2 which the Cisco detects:

Apr  7 13:18:29 devlns1-1 68258: Apr  7 12:18:29.155: ISAKMP:(0:0:N/A:0): vendor ID is NAT-T v2

However both ends settle on v3 so I don't think this is the problem:

Apr  7 13:18:29 devlns1-1 68303: Apr  7 12:18:29.179: ISAKMP:(0:1:SW:1): constructed NAT-T vendor-03 ID

Just to eliminate this, I've rebuilt openswan 2.4.5 commenting out the new
line in question:

		if (r) r = out_vendorid(np, outs, VID_NATT_IETF_02_N);

and nothing has changed.

Regards,

Brian.

[1] I've tried various combinations of
  "crypto ipsec fragmentation after-encryption"
and
  "crypto ipsec df-bit set"
  "crypto ipsec df-bit clear"
to no effect.