FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
sgiannogloudis
Description
This article describes techniques on how to identify, debug and troubleshoot IPsec VPN tunnels.

Solution
1) Identification

As first action, isolate the problematic tunnel. 
Enter the VDOM (if applicable) where the VPN is configured and type the command:
#get vpn ipsec tunnel summary
'to10.174.0.182' 10.174.0.182:0  selectors(total,up): 1/1  rx(pkt,err): 1921/0  tx(pkt,err): 69/2
'to10.189.0.182' 10.189.0.182:0  selectors(total,up): 1/0  rx(pkt,err): 0/0  tx(pkt,err): 0/0
On the particular output, two VPN tunnel, to10.174.0.182 & to10.189.0.182 are visible. The second VPN tunnel on the list has its selectors in a down state so the focus will be on that tunnel.

2) Phase 1 checks


After the problematic tunnel has been identified, it will be possible to  understand the status of phase 1.
To do so, type below command:
#diagnose vpn ike gateway list name to10.189.0.182

vd: root/0
name: to10.189.0.182
version: 1
interface: port9 10
addr: 10.189.0.31:500 -> 10.189.0.182:500
created: 15s ago
IKE SA: created 1/1
IPsec SA: created 0/0

  id/spi: 19576 a83334b3c66f871b/0000000000000000
  direction: responder
  status: connecting, state 3, started 15s ago
The important field from this particular command is status. Status field has a discrete output which can be either connecting or established.

1)    Established means Phase 1 is up and running

2)    Connecting means Phase 1 is down

If Phase 1 is down, do additional checks to identify the reason.

- Ensure bidirectional connectivity exists between the VPN gateways.

Try to traceroute towards the VPN peer, in our example, use commands:
#execute traceroute-options source 10.189.0.31
#execute traceroute 10.189.0.182

-Confirm IKE traffic for port 500 or 4500 is not blocked somewhere along the path.
To do so, perform a packet sniffer:
#diagnose sniffer packet any 'host 10.189.0.182 and port 500' 4 0 l
interfaces=[any]
filters=[host 10.189.0.182 and port 500]
- IKE debugging
If both of the above checks are successful, start debugging IKE protocol to check for possible configuration mismatches between the peers:

#diagnose vpn ike log-filter dst-addr4 10.189.0.182
#diagnose debug application ike -1
#diagnose debug enable
3) Phase 2 checks

If the status of Phase 1 is in established state, then focus on Phase 2. To do so, issue the command:
#diagnose vpn tunnel list name 10.189.0.182
list all ipsec tunnel in vd 0
name=to10.189.0.182 ver=1 serial=2 10.189.0.31:0->10.189.0.182:0
bound_if=10 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/8 options[0008]=npu
proxyid_num=1 child_num=0 refcnt=10 ilast=25 olast=25 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=534
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=to10.189.0.182 proto=0 sa=0 ref=1 serial=4
src: 0:172.16.170.0/255.255.255.0:0
dst: 0:192.168.50.0/255.255.255.0:0
The important field from the particular output is the ‘’sa’’. SA can have three values:
a) sa=0 indicates there is mismatch between selectors or no traffic is being initiated
b) sa=1 indicates IPsec SA is matching and there is traffic between the selectors
c) sa=2 is only visible during IPsec SA rekey

Lastly, there might be cases where the encryption and hashing algorithms in Phase 2 are mismatching as well.
In order to identify these kind of errors, run IKE debugging as it was descripted above.


Contributors