Community discussions

 
Petrw
just joined
Topic Author
Posts: 5
Joined: Sun Feb 04, 2018 1:17 pm

IKEv2/IPsec high latency

Sun Nov 10, 2019 7:19 pm

Allow me to ask for help to solve me with the following problem with latency. I have the network in which is on one side the Strongswan server and on the opposite side are terminals connected through DSL, cable or wifi. When I am testing latency through the IKEv2/IPsec tunnels in the directions from these terminals to the server and from server to these terminals with the datagram lengths from 40 to 8000 and the pinging intervals from 5s to 1min the RRT is from 25 to 50ms, so all is O.K. Now I had to connect to this network some terminals which are connected through LTE and these LTE terminals I have created from RBM33g + Huawei ME909s-120 module. When I am testing latency through the tunnels between these terminals and the server in direction from the terminal to the server with datagrams length from 40 to 1500 the RRT values are in interval 30-60ms (in average cca 45ms) (O.K). If the datagram length is larger than 1500 the packet does not pass to the server at all (?). The problem is with the latency in the opposite direction from the server to the LTE terminal. With the datagrams lengths from 40 to 1500 the RRTs varies between 40 to 700ms and sometimes from 200 to 1000ms. With these latencies the terminals are unusable for reliable bidirectional transfer of any data. The datagram larger then 1500 also does not pass from the server to the terminal (?).
When I insert to the LTE terminal the SIM card with public IP address and then I am testing the latency between the server and the terminal connected directly without the IPsec tunnel the RRT values are around 50ms in the both directions (O.K). The MTU and other parameters on the Debian strongswan server have their default values at present. I am not experienced on this field and I hope and believe with your help the mentioned problem will be successfully solved 8)

For any help thank you in advance.
 
sindy
Forum Guru
Forum Guru
Posts: 3904
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2/IPsec high latency

Sun Nov 10, 2019 9:15 pm

There are actually two points:
  • the datagram size limitation
  • the fact that the round-trip time differs depending on from which side you ping, did I get you right? I.e. the path is the same, but if you ping from the server and the terminal responds, the latency is much worse that when you ping from the terminal and the server responds, correct?

As for the datagram size, I would simply assume that the other-than-LTE paths support larger MTU than 1500 so larger datagrams can get through. Do you really need other than TCP datagrams larger than 1500 bytes or you've provided that information just to make the picture more complete?

As for the round-trip time difference, I can imagine the mobile network working principles to be the reason, although I'm no expert on this. But it sounds reasonable that if there is a period of silence, the modem goes to a kind of a sleep mode where it only "listens" on a service channel (with much less power spent), so if a packet comes from the network side, the modem has to get a wake-up message from the network first, which takes some time to be delivered and reacted to. So I'd do two types of test:
  • compare the behaviour of the tunneled traffic while using the "private-IP" SIM in the modem and while using the "public-IP" SIM in the same modem, to exclude any impact of different settings for different contracts,
  • with the private-IP SIM, look at the RTT if you ping from the server to the terminal with a higher rate, such as 1s or even 300ms. If my speculation is correct, the first ping after a long period of silence should be responded late, whereas the subsequent ones should be responded within the usual 50 ms.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
Petrw
just joined
Topic Author
Posts: 5
Joined: Sun Feb 04, 2018 1:17 pm

Re: IKEv2/IPsec high latency

Mon Nov 11, 2019 1:47 am

To the first point: we can left the datagram size limitation out because its 1500 length is sufficient for purpose.
To the second point: yes you are right.

I did now the latency test in both directions with the same SIM card which has public IP, through the IKEv2/IPsec tunnel and directly between the Strongswan server public IP and LTE terminal public IP. When I am pinging between public IP addresses from the server to the terminal and from the terminal to the server the RRTs are around 50ms in the both cases. When I am doing the same through the tunnel RRT is around 60ms (some time is probably required for encryption/decryption) when I am pinging from the terminal to the server. When I am pinging from the server to the terminal RRT are from 60 to 900ms.

In my opinion that implies the problem is not in LTE network but in the traffic in IPsec tunnel in direction from the server to the terminal when the MTU is strictly limited to 1500 on the terminal side because this is a limit of LTE path.
 
sindy
Forum Guru
Forum Guru
Posts: 3904
Joined: Mon Dec 04, 2017 9:19 pm

Re: IKEv2/IPsec high latency

Mon Nov 11, 2019 3:03 pm

When I am pinging between public IP addresses from the server to the terminal and from the terminal to the server the RRTs are around 50ms in the both cases.

When I am doing the same through the tunnel RRT is around 60ms (some time is probably required for encryption/decryption) when I am pinging from the terminal to the server. When I am pinging from the server to the terminal RRT are from 60 to 900ms.

In my opinion that implies the problem is not in LTE network but in the traffic in IPsec tunnel in direction from the server to the terminal when the MTU is strictly limited to 1500 on the terminal side because this is a limit of LTE path.
There is still a small chance that the mobile network is somehow responsible for the difference, because from the point of view of the network, the direct ping to the public address is an ICMP packet whereas a ping through the tunnel is a UDP packet (inside which the ICMP one is encapsulated).

In receiving direction, /tool sniffer will show you both the transport packet (UDP-encapsulated ESP) and the payload one (ICMP) decrypted from it. In sending direction, only the transport ones are sniffed. So it might make sense to sniff at both ends into a .pcap file and then look using wireshark where the delay occurs.

Once doing this, you may also want to look at how the 1500-byte packets are transported, you should see two transport packets per each payload one, because the IPsec headers occupy some extra bytes so the payload doesn't fit completely into a single transport packet.

But still it sounds weird, because the ICMP echo request and ICMP echo reply to it are equal in size and both have to pass through the tunnel, so the difference in behaviour between the two cases (echo request sent from terminal and response coming from server vs. echo request sent from server and response coming for terminal) makes little sense.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: No registered users and 148 guests