Effects of packet drop and latency on IPSEC tunnels

When I was a junior engineer, I used to go to customer sites to install leased line modems and perform the initial quality checks of the lines. The most critical moment after provisioning the line was sending the first 100 ICMP packets to see if there is any packet loss or not and even if there is a single packet loss, it was a nightmare for us to find where the packet was really lost. Starting from physical layer i.e checking cablings or if it is a wireless link checking weather conditions etc 🙂 and then protocol level investigations. If we were lucky enough, it was our problem as Telco involvement wasn’t required. If it was a Telco problem unfortunately it was worse as convincing Telco that they have a problem wasn’t really an easy task during that period.
I have started with a little story but in today’s networks, packet losses aren’t so common but it happens or if you have a satellite link, latencies might go up to 1000ms even more. I will do an experimental work here as to how IPSEC tunnel establishment might be affected by packet loss/latency.


For this lab, we are going to use the above topology in which there is an established IPSEC tunnel between branchG and CO-A-1 SRX devices.

First of all we test the round trip times between each of the IPSEC end points.

According to the test, we have average 12ms round trip time. Jitter is also negligible I believe.

Now I am restarting KMD and check how long it may take for the IPSEC tunnel to come up.

Almost in the blink of an eye, tunnel comes up.

Now wan emulation (netem) part comes into play in Linux, this is a wonderful feature, believe me! we are adding 1000ms of delay to every packet on our uplink of branchG towards the central office device.

Now we do the same round trip test to see how the response time is affected.

and we can see that, our link latency has increased quite dramatically. Average round trip has become 1011ms.

Let’s see how long IPSEC tunnel establishment takes.

Now we have a couple of seconds delay but still reasonable I believe. We can increase the delay but don’t see the point as more than 1000ms delay shouldn’t be an acceptable latency.

Now we are deleting the delay and simulating 20% packet drop.

And now let’s ping the remote IPSEC peer

We have wonderfully lost 22% of packets as you can see from the outputs. You may get slightly different drop rates actually.

Once we have added this packet drop emulation, we check packet capture between these two end points to see the packet drops.


If you closely look at the pcap outputs taken on two interfaces i.e eth1.251 and eth1.956 which are downstream and upstream interfaces, you can see the packet drops but dropped packet is re-sent by the peer and these drops delay Quick Mode completion around 30 seconds.

If you keep increasing the packet drop rate to even 40%, SRX establishes the IPSEC tunnel. For example, if initiator doesn’t get any response packet to its first packet containing proposals, it keeps sending with 10seconds interval. With 40% rate, it can take up to 1,5-2 minutes to establish the tunnel. I have even made things worse by adding 1000ms latency but tunnel got established. However I recall that in several of my tests, 35-40% packet loss was really causing trouble but I haven’t seen any issue on my latest tests.
One last thing I need to mention is the MTU. During the Phase 1 packet exhanges, the largest packet is the first packet sent by the initiator containing proposals, DPD support etc and the total IP packet size probably won’t be larger than 350bytes hence small MTU shouldn’t become a concern here either.

In a nutshell, this experiment who knows how much perfect it is, indicates that neither packet loss nor latency isn’t a threat for IPSEC tunnel establishment including a small MTU size.

If you have any story, please do share here!

I wish you days without any packet loss 🙂

4 thoughts on “Effects of packet drop and latency on IPSEC tunnels

  1. Ray

    Do you have a SRX multipoint-to-multipoint (full mesh) example I can borrow: HUB to B1/B2 and B1 to B2. without B1 or B2 to reach each other.


You have a feedback?