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

[Martin Sand]

Thanks again Noel.

I have executed `traceroute -T --mtu <destination>` and `mtr -rw 
<destination>` on machines at both locations.
I did not do further investigation on the MSS yet since I have this 
strange packet loss.
Based on the route, I assume this happens at the hub which is in between 
the two routers?
Could this be the root cause I need to further investigate?

Kind regards
Martin

traceroute -T --mtu pi-frankfurt
traceroute to pi-frankfurt (192.168.2.135), 30 hops max, 60 byte packets
  1  router-freiburg (192.168.1.1)  0.263 ms  0.179 ms  0.172 ms
  2  * * *
  3  router-frankfurt (192.168.2.1)  41.762 ms  41.182 ms  36.716 ms
  4  pi-frankfurt (192.168.2.135)  36.693 ms  43.629 ms  37.051 ms

traceroute -T --mtu pi-freiburg
traceroute to pi-freiburg (192.168.1.130), 30 hops max, 60 byte packets
  1  router-frankfurt (192.168.2.1)  0.489 ms  0.381 ms  0.287 ms
  2  * * *
  3  router-freiburg (192.168.1.1)  38.368 ms  47.673 ms  35.441 ms
  4  pi-freiburg (192.168.1.130)  39.456 ms  54.566 ms  36.117 ms

mtr -rw pi-frankfurt
Start: 2017-12-27T22:57:40+0100
HOST: workstation              Loss%   Snt   Last   Avg  Best Wrst StDev
   1.|-- router-freiburg         0.0%    10    0.2   0.2   0.2 0.3   0.0
   2.|-- ???                      100.0    10    0.0   0.0   0.0 0.0   0.0
   3.|-- router-frankfurt        0.0%    10   33.3  35.5  32.5 42.0   2.7
   4.|-- pi-frankfurt              0.0%    10   33.5  34.4  32.7 36.7   1.5


On 27.12.2017 21:08, Noel Kuntze wrote:
> 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
>>>>