[Swan] Windows IKEv2 Error 809

[Tom Robinson]

Hi Paul,

On 25/05/16 15:21, Tom Robinson wrote:
> Hi Paul,
> 
> Thanks for taking the time to look at this.
> 
> On 25/05/16 00:33, Paul Wouters wrote:
>> On Mon, 23 May 2016, Tom Robinson wrote:
>>
>>> I've having trouble connecting Windows 8 to libreswan (version 3.15-5) using IKEv2. I get the 809
>>> error.
>>>
>>> The ipsec connection I have configured is copied from another libreswan host (version 3.13-1) that
>>> does work (we're migrating) but I can't seem to locate the issue on the new server.
>>>
>>> The connection appears to succeed on the server. Then, on the Windows 8 client, I see a message
>>> "Verifying your credentials" after which I see the "Error 809: ..." message.
>>>
>>> Here's my log of the connection:
>>
>>> May 23 11:29:39 apex pluto[29341]: "ikev2-cp"[1] 165.228.94.4 #9: STATE_PARENT_R2: received v2I2,
>>> PARENT SA established tunnel mode {ESP/NAT=>0xefe27442 <0x1fd6e1dc xfrm=AES_128-HMAC_SHA1 NATOA=none
>>> NATD=165.228.94.4:4500 DPD=active}
>>
>> So the tunnel came up fine. I am not sure why Windows is rejecting it.
>>
> 
> I can still connect to the old VPN from the same client. I've scrutinised both the old an new client
> settings and can't find anything out of place.
> 
> On the server, I've gone over and over again the firewall settings but can't spot anything there either.
> 
>>> For my own sanity, is someone able to run their eyes over this?
>>
>> Looked fine. Perhaps it is a timing/clock issue with the certificate?
> 
> I had the same thought yesterday. I did find an ntpd sync issue and fix it (the clock was five
> seconds fast). Time is sync'd now but still no joy from the VPN. :-/ I've even rebooted the server.
> I have since checked the client's clock and found that five seconds fast as well. I've sync'd that
> now to 'Internet Time' under Windows and the time reports the same as the server now. Still no joy
> for the Roadwarrior IKE connection, though.
> 
> Just so you know, this server will carry three VPNs connections in the long run; two host-to-host
> and one Roadwarrior IKE. One of the host-to-host connections uses PSK and the other certificates. I
> got the certificate based host-to-host VPNs migrated today and that works fine.
> 
> 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.

-------------- 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/20160525/95f5f4f6/attachment.sig>