<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 11/7/2017 07:37, Tobias Brunner wrote:<br>
<blockquote type="cite"
cite="mid:45d358ce-c3c8-f9db-3fe6-8bf973dbb1a3@strongswan.org">
<pre wrap="">Hi Joshua,
</pre>
<blockquote type="cite">
<pre wrap=""> I got some problems about the configuration of strongswan, no matter
how I configured the IKEv2 connection just couldn't establish.
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext" href="https://wiki.strongswan.org/issues/965#note-1">https://wiki.strongswan.org/issues/965#note-1</a>
</pre>
</blockquote>
Yeah, what Tobias said.<br>
<br>
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.<br>
<br>
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.<br>
<br>
EAP with username/password as an authentication method won't help;
the response is still too big.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
</div>
</body>
</html>