Fortigate to Fortigate IPSec overhead

[jokes54321]

Hello,

I'm seeing what I believe is high latency on on an IPSec tunnel between a branch and our data center.

Datacenter

- 1500d HA Pair active/active

- 6.0.10

- 1Gb DIA circuit

Branch

- 60e

- 6.2.4

- broadband circuit

From the branch, I'm running a continuous 1400 byte ping to the data center WAN interface and am seeing a consistent 82ms average latency. I'm running another continuous 1400 byte ping over IPSec to a network device attached to an inside interface of the 1500d and am seeing ~127 ms average latency, with spikes up to 310ms. As more devices run traffic over the IPSec, the tunnel latency increases while the pings to the 1500d WAN interface stays rather consistent.

I've adjusted MTU and MSS settings and forced the tunnel to use UDP and squeezed a slight performance increase out of it, but not much.

I'm wondering if this is typical overhead for IPSec on these devices? It seems a bit high to me.

Denny

[Toshi_Esumi]

Our simple IPSec VPN with 60E in Seattle, WA to 1000D(a-p) in Dallas, TX shows below for 1400Byte pings.

outside the tunnel: 69.4 ms

inside the tunnel: 69.9 ms

in average. So somthing is adding up the latency in your case. What I would do is ....

1. to comare apple to apple (eliminate internal portion outside the FGT), I'll ping tunnel interface IP over the tunnel. If you haven't configured tunnel IPs, assign a pair of IPs.

2. make sure you followed the HW acceleration guide for 1500D for ingress/egress ports.

https://docs.fortinet.com/document/fortigate/6.0.0/hardware-acceleration/448300/hardware-acceleratio...

3. In a maintenance window, shut down/disconnect one of HA unit to see if A-A HA is adding something.

If none of them above change the symptom, I would open a TT at TAC to get it looked at your config and the units.

[emnoc]

FWIW, You have two very different models. Those numbers might be normal for the 60e.

If your worried about the latency try a different protocol and tracking any improvement ( i.e 3des vsr aes ) .

Ken Felix