Description
This article describes techniques on how to identify, debug and troubleshoot issues with IPsec VPN tunnels.
Scope
FortiGate.
Solution
- Identification.
As the 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 tunnels, 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 the 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. The status field has a discrete output that can be either connected or established.
- Established means Phase 1 is up and running.
- Connecting means Phase 1 is down.
If Phase 1 is down, perform additional checks to identify the reason.
- Ensure bidirectional connectivity exists between the VPN gateways.
Try to traceroute towards the VPN peer, in this example, use the 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]
Note:
In case of nattraversal is enabled under phase1 and FortiGate is behind the NAT then sniffer traffic with 'udp port 4500'.
IKE debugging: If both of the above checks are successful, start debugging the 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
Note: Starting from FortiOS 7.4.1, the "diagnose vpn ike log-filter dst-addr4" command has been changed to "diagnose vpn ike log filter rem-addr4".
diagnose vpn ike log filter rem-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 an 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:
- sa=0 indicates there is a mismatch between selectors or no traffic is being initiated.
- sa=1 indicates IPsec SA is matching and there is traffic between the selectors.
- sa=2 is only visible during IPsec SA rekey.
Lastly, there might be cases where the encryption and hashing algorithms in Phase 2 are mismatched as well.
In order to identify this kind of error, run IKE debugging as it was described above.
Related documents:
Troubleshooting Tip: IPsec Site-to-Site Tunnel Connectivity.
IPsec-related diagnose command.
