[Swan] Windows IKEv2 Error 809

Thu May 26 05:49:47 UTC 2016

On 25/05/16 16:32, Tom Robinson wrote:
> On 25/05/16 16:22, Tom Robinson wrote:
>>> Below is a network trace of the Windows connection being established. Should I be worried about the
>>> Fragmentation? On the firewall I have clamped the MSS to 1400 for IPSEC tunnelling.
>>>
>>>   1 0.000000000 165.228.94.4 -> 115.70.189.242 ISAKMP 922
>>>   2 0.001086847 115.70.189.242 -> 165.228.94.4 ISAKMP 339
>>>   3 0.048702978 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=0, ID=47b2)
>>>   4 0.061718266 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=1368, ID=47b2)
>>>   5 0.066892052 165.228.94.4 -> 115.70.189.242 ISAKMP 594
>>>   6 0.076894733 115.70.189.242 -> 165.228.94.4 IPv4 1514 Fragmented IP protocol (proto=UDP 17,
>>> off=0, ID=848d)
>>>   7 0.076953733 115.70.189.242 -> 165.228.94.4 ISAKMP 474
>>>   8 1.048806004 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=0, ID=47b3)
>>>   9 1.061378747 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=1368, ID=47b3)
>>>  10 1.066515615 165.228.94.4 -> 115.70.189.242 ISAKMP 594
>>>  11 1.066817202 115.70.189.242 -> 165.228.94.4 ISAKMP 343
>>>  12 2.061653284 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=0, ID=47b4)
>>>  13 2.074207523 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
>>> off=1368, ID=47b4)
>>>  14 2.079655604 165.228.94.4 -> 115.70.189.242 ISAKMP 594
>>>  15 2.079883081 115.70.189.242 -> 165.228.94.4 ISAKMP 343
>>>  16 14.955166129 115.70.189.242 -> 165.228.94.4 ISAKMP 106
>>>  17 15.086739890 115.70.189.242 -> 165.228.94.4 ISAKMP 106
>>
>>
>> On the firewall I've lowered the MSS to 1398 and it's working now. Why does this connection needs
>> two extra bytes to be happy? It's actually traversing the same internet link.
> 
> I'm not really understanding what just happened. Although it's connecting now without error I'm
> still seeing fragmentation on VPN connection startup:
> 
>   1 0.000000000 165.228.94.4 -> 115.70.189.242 ISAKMP 922
>   2 0.001094248 115.70.189.242 -> 165.228.94.4 ISAKMP 339
>   3 0.064956489 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
> off=0, ID=13c1)
>   4 0.078018322 165.228.94.4 -> 115.70.189.242 IPv4 1402 Fragmented IP protocol (proto=UDP 17,
> off=1368, ID=13c1)
>   5 0.083183106 165.228.94.4 -> 115.70.189.242 ISAKMP 594
>   6 0.148332286 115.70.189.242 -> 165.228.94.4 IPv4 1514 Fragmented IP protocol (proto=UDP 17,
> off=0, ID=96ac)
>   7 0.148368257 115.70.189.242 -> 165.228.94.4 ISAKMP 474
>   8 0.217055356 165.228.94.4 -> 115.70.189.242 ESP 126 ESP (SPI=0x8c512869)
>   9 0.218572760 165.228.94.4 -> 115.70.189.242 ESP 126 ESP (SPI=0x8c512869)
>  10 0.234054672 165.228.94.4 -> 115.70.189.242 ESP 126 ESP (SPI=0x8c512869)
>  11 0.238590112 165.228.94.4 -> 115.70.189.242 ESP 126 ESP (SPI=0x8c512869)
>  12 0.240755201 165.228.94.4 -> 115.70.189.242 ESP 158 ESP (SPI=0x8c512869)
>  13 0.245197092 165.228.94.4 -> 115.70.189.242 ESP 414 ESP (SPI=0x8c512869)

I'm beginning to think my MSS change on the firewall was just luck. Fragmentation is still an issue.
I've set the MSS back to 1400 as that's what I have on the old (working) server.

I've analysed the packets for both connections (remember; one connection is old and works and the
other is new and fails).

On the old connection the IKE_AUTH packet from the client gets fragmented into three and then
reassembled. It's 3296 bytes on reassembly. The server responds with IKE_AUTH and the connection
comes up without any further fragmentation. At this stage I see lots of ESP packets coming to and fro.

On the new connection the IKE_AUTH progresses in the same way as for the old connection (packet from
the client gets fragmented into three and then reassembled. It's also 3296 bytes). The server
responds with IKE_AUTH four times but the client seems to ignore it and resends another IKE_AUTH
packet instead. This packet gets fragmented as before. After packet reassembly, the server then
responds with IKE_SA_INIT. The client seems to ignore this again and resends another fragmented
IKE_AUTH. The client gives up with "Error 809".

I have only analysed the connections from the server end at this stage. I'll take a look on the
client to see if I can determine what it's doing with the IKE_AUTH packets sent from the server.

Anyone else have a few clues?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20160526/c9f7c239/attachment.sig>