[strongSwan] using 500/tcp
tobias at strongswan.org
Wed Jul 20 17:03:44 CEST 2016
As you noticed the IKE_AUTH packet is the one that's problematic. But
since Mac OS X supports IKEv2 fragmentation
> Notify (IKEv2 Fragmentation Supported) Payload:
> No Data
there is really no reason not to enable it (unless you use an old
strongSwan version that does not support it yet).
>>> Looking at this I wonder if it is reasonable to ignore 500/tcp
>>> for Strongswan?
>> Until  is standardized this won't change (it also requires kernel
>> changes for ESP in TCP encapsulation).
> Understood. Not to mention that the peer (MacOS) has to support
> it as well.
Yes, but Apple is one of the primary drivers behind this extension (the
main author actually works for Apple). So I guess theirs will be one of
the first IKEv2 implementations to support it (but that will also depend
on their release cycle).
> I just wonder if you have any recommendations to avoid this delay?
> In the sample above the delay was just 3 seconds, but sometimes its
> 10 seconds or more.
What delay are you referring to exactly? In the log you sent it looks
like the timespan between sending the IKE_SA_INIT request and giving up
because the IKE_AUTH response was not received is about 12 seconds.
I also wonder if the problem is the request or the response not getting
fragmented properly (you might want to check with tcpdump/Wireshark to
see who sends messages that are too large and where the ICMPs come from,
and if there are any retransmits).
> Once the MTU is known the IKEv2 negotiations work very well. I tried
> to ping6 the peer with -s 1500 before initiating the IPsec connection,
> but this did not help.
You might have to use the -m option on Mac OS X as it looks like the
packet will otherwise be fragmented at 1280 bytes (minimum IPv6 MTU).
Afterwards you can check the cached PMTU with `ip route get <IP>` on
Linux, and on Mac OS X `netstat -f inet6 -narl` should show the MTU for
More information about the Users