[strongSwan] Tunnel over [slow] GPRS link
noel.kuntze+strongswan-users-ml at thermi.consulting
Fri Apr 28 17:17:00 CEST 2017
On 28.04.2017 10:06, Rene Maurer wrote:
> It is not clear for me in which direction I should go to solve the
> Is there a general problem when using GPRS (or UMTS) connections?
> Is connection speed relevant?
> Is fragmentation involved? Should/must it be disabled or enabled when
> using slow (any maybe not stable) connections
Well, it can be that some large IKE packets are fragmented on the IP layer or completely dropped.
By default, the kernel sends out UDP packets with the "don't fragment" bit set, so maybe they're just dropped
and no ICMP error message is received by the kernel.
set net.ipv4.ip_no_pmtu_disc=1 in sysctl (try it temporary by executing `sysctl -w net.ipv4.ip_no_pmtu_disc=1`).
That makes the kernel not set the "Don't fragment bit", but net.ipv4.ip_no_pmtu_disc applies globally. So the kernel
will never try to discover the path MTU. Read the paragraph about "ip_no_pmtu_disc" on the kernel.org website to understand what the setting
Try to enable IKE fragmentation, if you can, by setting "fragmentation=yes".
That will enable fragmentation if the remote peer supports it. Also set charon.fragment_size to 500 or 600 to test it. The default of "1280"
that is mentioned in the man page that I have here, is larger than the size of the packet.
> Are there any timing parameters in strongSwan we can change to achieve
> a more robust behavior?
I do not understand the intention of the question, because retransmission is not your problem.
The problem is that the message gets lost (or not answered by the remote peer).
> Is it better to use "aggressive mode"?
Doesn't exist in IKEv2, because it's pointless. IDs are sent in the clear in IKEv2.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the Users