You can’t really debug VPN problems with static show commands, if VPN fails to function you HAVE to
see it happening real-time. Below I list few debug commands that do just that for IPSEC site-to-site
tunnels in Fortigate.
Here:
192.168.168.254 – IP address on the LAN interface of the fortigate
10.170.15.131′ – IP address on the remote LAN
200.199.20.162 – (sanitazed) IP of the wan interface of Fortigate
72.21.207.65 – (sanitazed) IP of the remote VPN peer
-Enable debugging
FG100A# diag debug en
- Enable debug messages for specific application , here we are interested in IKE (note debug level -1,
following logic I enabled first +1, 255 etc and surprisingly had no effect at all )
FG100A # diag debug app ike -1
I, personally, prefer also to do sniffer on the tests I do after, so:
FG100A # diagnose sniffer packet any ‘host 10.170.15.131′
Now open another ssh session to the same FG and do pings to IP on the other side of VPN tunnel
with source IP of internal LAN (or just ask client to do pings from LAN, depends on encryption domain) :
- Configure pings to go with the source interface of LAN of the Fortigate:
FG100A # exec ping-options source 192.168.168.254
- No wdo pings to bring up the VPN tunnel
FG100A # exec ping 10.170.15.131
PING 10.170.15.131 (10.170.15.131): 56 data bytes
64 bytes from 10.170.15.131: icmp_seq=1 ttl=252 time=73.2 ms
64 bytes from 10.170.15.131: icmp_seq=2 ttl=252 time=116.3 ms
64 bytes from 10.170.15.131: icmp_seq=3 ttl=252 time=110.3 ms
64 bytes from 10.170.15.131: icmp_seq=4 ttl=252 time=138.4 ms
Now return to the 1st ssh session and you will see:
interfaces=[any]
filters=[host 10.170.15.131]
0:Robophone1:Robophone1/2: IPsec SA connect 3 200.199.20.162->72.21.207.65:500 , natt_mode=0
0:Robophone1: using existing connection, dpd_fail=0
0:Robophone1: found phase2 Robophone1/2
0:Robophone1: IPsec SA connect 3 200.199.20.162->72.21.207.65:500 negotiating
0:Robophone1:1990: cookie d3351433913f978c/069bcd9a38263f3a:5125b9f3
0:Robophone1:1990:Robophone1/2:471585: initiator selectors 0 200.199.20.162:0->10.170.15.131:0
0:Robophone1:1990: sent IKE msg (quick_i1send): 200.199.20.162:500->72.21.207.65:500, len=148
Robophone: Initiator: sent 72.21.207.65quick mode message #1 (OK)
0: comes 72.21.207.65:500->200.199.20.162:500,ifindex=3….
0: exchange=Quick id=d3351433913f978c/069bcd9a38263f3a:5125b9f3 len=156
0: found Robophone1 200.199.20.1623 -> 72.21.207.65:500
0:RobophoneRobophone1:1990:Robophone1/2:471585: responder selectors 0 200.199.20.162:0->10.170.15.131:0
0:Robophone1:1990: sent IKE msg (quick_i2send): 200.199.20.162:500->72.21.207.65:500, len=60
0:Robophone1:1990:Robophone1/2:471585: set sa life soft seconds=1775.
0:Robophone1:1990:Robophone1/2:471585: set sa life hard seconds=1800.0:Robophone1:1990:Robophone1/2:471585: add SA #src=1 #dst=1
0:Robophone1:1990:Robophone1/2:471585: src 0 4 192.168.168.0/255.255.255.0
0:Robophone1:1990:Robophone1/2:471585: dst 0 1 10.170.15.131
0:Robophone1:1990:Robophone1/2:471585: installed SA: SPIs=2f1c289f/ea7a510d
0:Robophone1:1990:Robophone1/2:471585: sending SNMP tunnel UP trap
Robophone1: Initiator: sent 72.21.207.65 quick mode message #2 (DONE)
15.153033 10.170.15.131 -> 200.199.20.162: icmp: echo reply
16.196213 10.170.15.131 -> 200.199.20.162: icmp: echo reply
17.190216 10.170.15.131 -> 200.199.20.162: icmp: echo reply
18.218259 10.170.15.131 -> 200.199.20.162: icmp: echo reply
4 packets received by filter
0 packets dropped by kernel
Dont forget to disable debug afterwards
FG100A # diag debug app ike 0
Follow me on Twitter
very useful information, thanks for sharing.
Thanks for sharing! this info helps me a lot.
like your post’s YURI!
Thx