[strongSwan] Performance (latency) in a Hub and Spoke setup

[Noel Kuntze]

Hi,

You can test the convergence speed using `traceroute -T --mtu <destination>`, but that only gives you the MTU. You need to manually discover the MSS
using `traceroute -T -O mss=<mss> <destination>`.

The best way to check if the problem continues is to just run tcpdump/wireshark and check for ICMP Fragmenation needed packets and TCP errors or timeouts.

Kind regards

Noel

On 27.12.2017 17:12, Martin Sand wrote:
> Thanks Noel. Sorry, I had to travel to the other location (350 km).
>
> I adapted the iptable rules. It improved, but I have the impression it only improved a bit.
> Is there a way to measure MTU discovery time?
>
> Kind regards
> Martin
>
>
> On 14.12.2017 13:51, Noel Kuntze wrote:
>> Hi,
>>
>>> VPN internal http requests to a web server of another spoke take some time until the page is rendered.
>>> I assume this is due to the latency.
>> Nah. It's extremely more likely that the path MTU discovery takes some time (maybe due to some missing/wrong firewall rules on some host(s) in your network topology).
>> Try lowering the MTU and MSS of the tunneled traffic[1].
>>
>> Kind regards
>>
>> Noel
>>
>> [1] https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues
>>
>> On 14.12.2017 13:41, Martin Sand wrote:
>>> Hi all
>>>
>>> I have a Hub and Spoke setup. Connections are working perfectly fine.
>>> Throughput is almost reaching the maximum rate of the upload channel speed, 10 MBit/s.
>>>
>>> Unfortunately the latency is not fulfilling my objectives. I have an average ping time of 39 ms (see below) when pinging clients on other spokes.
>>> VPN internal http requests to a web server of another spoke take some time until the page is rendered.
>>> I assume this is due to the latency.
>>>
>>> Is there any chance to improve the latency? Or is the latency perfectly good?
>>>
>>> Best regards
>>> Martin
>>>
>>> Hub internet address
>>> 64 bytes from vpn.example.com (217.122.5.6): icmp_seq=1 ttl=57 time=15.2 ms
>>>
>>> Internal address of Hub
>>> PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.1: icmp_seq=1 ttl=62 time=40.4 ms
>>>
>>> Client on another spoke
>>> PING 192.168.1.130 (192.168.1.130) 56(84) bytes of data.
>>> 64 bytes from 192.168.1.130: icmp_seq=1 ttl=61 time=108 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=2 ttl=61 time=41.8 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=3 ttl=61 time=38.0 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=4 ttl=61 time=35.2 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=5 ttl=61 time=36.4 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=6 ttl=61 time=39.1 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=7 ttl=61 time=38.1 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=8 ttl=61 time=41.6 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=9 ttl=61 time=36.0 ms
>>> 64 bytes from 192.168.1.130: icmp_seq=10 ttl=61 time=36.7 ms
>>>
>>> --- 192.168.1.130 ping statistics ---
>>> 10 packets transmitted, 10 received, 0% packet loss, time 9013ms
>>> rtt min/avg/max/mdev = 35.295/45.159/108.281/21.146 ms
>>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20171227/163bde35/attachment.sig>