[strongSwan] Couldn't establish IKEv2 vpn connection using strongswan, log shows timeout

Karl Denninger karl at denninger.net
Tue Nov 7 16:02:05 CET 2017

On 11/7/2017 07:37, Tobias Brunner wrote:
> Hi Joshua,
>>     I got some problems about the configuration of strongswan, no matter
>> how I configured the IKEv2 connection just couldn't establish.
> This doesn't look like a configuration issue but a network problem.  The
> client does not seem to receive the IKE_SA_INIT response sent by the
> server (at least initially) and, therefore, retransmits the request a
> couple of times.  It seems to stop after two retransmits so it might
> have received the response eventually.  But since the server doesn't
> receive an IKE_AUTH request it could mean that there is an IP
> fragmentation issue (also check for errors on the client).  If the
> IKE_AUTH request gets too big (e.g. because of lots of certificate
> requests or a large client certificate) it gets fragmented into multiple
> IP packets and if some firewall/router between client and server drops
> such fragments the server won't receive the full message.
> As this seems to be a Windows client you might not have a lot of options
> as Windows doesn't support IKEv2 fragmentation.  If you use certificate
> authentication for the client you could try to switch to EAP with
> username/password (but it's possible that the server's IKE_AUTH response
> will get fragmented too).  Also see [1].
> Regards,
> Tobias
> [1] https://wiki.strongswan.org/issues/965#note-1
Yeah, what Tobias said.

This looks like Windows as a client.  Windows' IKEv2 VPN client doesn't
support IKE fragmentation and thus doesn't ask for it.  StrongSwan does
support it, but the client has to as well.

The result is that when you try to initiate a connection the network
level is responsible for fragmenting and reassembling the response. 
Many networks are configured to intentionally drop fragments (which is
due to a false belief this somehow helps them resist common attacks)
which means that the response will NEVER get through in full, and thus
the connection won't come up.

EAP with username/password as an authentication method won't help; the
response is still too big.

Microsoft has refused to update their client "forever"; this has been an
issue since at least Windows 7, and there's really no excuse for
Microsoft's failure to fix it, but unfortunately there's not much you
can do about it unless you can find a way to force Redmond to get its
head out of its posterior.

I wound up moving to OpenVPN for Windows clients as a result of this
problem which (sadly) requires I run a second server process (and manage
that) on the server end.

Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171107/6deeb298/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171107/6deeb298/attachment-0001.bin>

More information about the Users mailing list