[strongSwan] Troubleshooting VPN performance

Zach Cutlip uid000 at gmail.com
Mon Apr 10 16:40:17 CEST 2017


Just to clarify: are you referring to
charon.plugins.kernel-netlink.mss and
charon.plugins.kernel-netlink.mtu?

Do the clients require any configuration change?



On Tue, Apr 4, 2017 at 11:59 AM, Noel Kuntze <noel at familie-kuntze.de> wrote:
> Hello Zach,
>
> On 30.03.2017 07:58, Zach Cutlip wrote:
>> Hello,
>>
>> I'm using StrongSwan in a road warrior configuration that allows me to
>> VPN all my smartphone and laptop traffic through my home internet
>> connection. When I'm away from home, my devices automatically connect
>> from my MacBook and iPhone.
>>
>> This works really well, with speeds generally approaching my home
>> internet service's upstream limit of 10Mbps, which is the bottleneck.
>>
>> The only exception is when I'm on the commuter bus to and from work
>> using the bus's WiFi. The on-bus WiFi's speed without the VPN
>> connected is generally around 15-30 Mbps, as tested by fast.com (over
>> HTTPS, so caching shouldn't be an issue) as well as ssh/scp. However,
>> when I connect to the VPN while on the bus, the performance becomes
>> nearly unusable; less than 1Mbps, sometimes around a few hundred Kbps.
>>
>> In case it matters, I'm guessing the bus uses some sort of cellular
>> backhaul. The public IP address block belongs to Clearwire, which I
>> think is owned by Sprint.
>>
>> I'm not sure how I would begin troubleshooting this:
>> - Is there any particular way should I configure logging on either the
>> server or the client?
>> - Are there any particular things I should look for in the longs?
>> - Is there anything I should look for in packet captures either on the
>> client or the server?
>> - Any other things I should look for?
>>
>> Thanks,
>> Zach
>
>
> Try lowering the MSS and MTU inside the tunnel to
>
> 1200 and 1300. There might be some MSS fixing happening on the
> mobile backhaul.
>
> You can use the instructions from the wiki to get a good traffic dump.
> I guess there are simply a lot of retransmissions, because of the dropped
> packets and nothing more. Maybe the WiFi does aggressive QoS
> and drops all the ESP/UDPENCAP packets.
>
> --
>
> Mit freundlichen Grüßen/Kind Regards,
> Noel Kuntze
>
> GPG Key ID: 0x63EC6658
> Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658
>
>



-- 
:wq!


More information about the Users mailing list