Testing IPSEC VPN latency

[FortiOSman]

Hello,

Are there any good ways to test IPSEC VPN tunnel latency from the FortiGate? I currently just ping one of the endpoints from the CLI but was wondering if anyone does something differently. Ideally I would like this graphed out, but I do not think there is anything native that would do this. 

Looking forward to your responses.

[Toshi_Esumi]

That's what I do too.

[emnoc]

Pinging a vpn remote-gw  end-point is not passing traffic  thru the IPSEC tunnel.  If you goal is to test latency thru the tunnel,  you need to monitor the traffic  that goes thru the  tunnel.

If you want a type of advance-latency monitoring and have a local-subnet allowed thru the  tunnel that uses  TCP, you could craft a  simple checker that measures the timestamp of the TCP  SYN and the response of the SYN-ACK. This will give you  an ideal of "actual" RTT. If you want one-way latency you will have to creative and monitor  A-------> B SYN ( CS ) and  then  B------A SYN_ACK ( SC ) to gather  each path one-way measurement. Latency is not always equal in both directions.

CS = client2server

SC = server2client

Ideally I would like this graphed out, but I do not think there is anything native that would do this.

These could be monitored,  and graph if required.  Example in nagios you would need to write a custom check apply it.

FWIW: the  tunnel-interface has an assigned  SNMP IfIndex and you can graph it just like any physical interface

e.g

FGT40DCHIIL (root) $ show system  interface   VPNCHKP1 | grep snmp-index         set snmp-index 124

Ken

[FortiOSman]

Thanks. To clarify, I ping a device on the other side of the tunnel, not the actual remote-gw ip. 

FWIW: the  tunnel-interface has an assigned  SNMP IfIndex and you can graph it just like any physical interface

What kind of data are you graphing? The only graphs I have in the FortiGate show interface traffic history.

[emnoc]

Take a look at  tcptrace tool and if you are into  GNUplot you can craft  various layer4   graphs

e.g

https://blog.cloudflare.com/the-story-of-one-latency-spike/