Staff & Editor

Troubleshooting Tip: Troubleshooting IPsec site-to-site tunnel connectivity

September 21, 2026 at 11:46 AM
0 replies
549388 views

Description

This article describes how to troubleshoot basic IPsec tunnel issues and collect the data required by TAC for VPN investigation.

IKE is the process responsible for negotiating Phase 1 and Phase 2. Follow the steps below to troubleshoot a VPN tunnel that is not active or passing traffic.

Scope

FortiGate, IPsec.

Solution

Step 1: Understand which type of tunnel has issues.

FortiOS supports:

Site-to-Site VPN.
Dial-Up VPN.

Capture the exact failure mode before changing anything.
Record one disconnect with timestamps:

get vpn ipsec tunnel summary
diagnose vpn tunnel list name <tunnel>
diagnose vpn ike gateway list name <tunnel>

Note these fields from diagnose vpn tunnel list:

status: up vs down.
created / expires (Phase-1 and Phase-2 lifetime).
dec: / enc: packet counters frozen or incrementing.
npu_flag.
DPD mode and last DPD send/receive time.

If Phase-1 stays up and Phase-2 counters stop, this is not an IKE bring-up problem. Treat it as path, ESP, NPU, or dirty-session.

Note:

The npu_flag value in the diagnose vpn tunnel list output indicates ESP hardware offload status: 00 = no offload (software path), 01/02 = one-directional offload only, 03 = full RX+TX offload (optimal). 20 means the cipher or HMAC is unsupported for offload, 40 means the NPU SA sequence number space is exhausted, and 80 marks a dirty SA that is expiring and should no longer be used - this is the dirty-session case referenced above.

Related article:

Technical Tip: Ensuring IPsec traffic is offloaded for improved throughput

Step 2: Determine whether the Phase-2 Status is 'UP'.

No (SA=0) - Continue to Step 3.
Yes (SA=1) - If traffic is not passing, - Jump to Step 6.
Flapping - SA is flapping between the 'UP' and 'Down' states - Jump to Step 7.

Note:

Phase-2 status can be found from both the GUI and the command line.

From the GUI:

When Phase2 is Down:

When Phase2 is Up:

Note:

One more way to check the IPsec monitor status from the GUI is by selecting the up or inactive name under status in the IPsec tunnel. The image is attached below.

From the CLI:

Execute the command 'diagnose vpn tunnel list name <phase1-name>' to view the Phase2 status for a specific tunnel.

Note:

'diagnose vpn tunnel list', can also be executed to view the Phase2 status of all tunnels.

When Phase2 is Down:

When Phase2 is Up:

Step 3: IKE Phase1 up.

No (State – 'Connecting') - Continue to Step 4.
Yes (State – 'Established') - Jump to Step 5.

Execute the command 'diagnose vpn ike gateway list name <phase1-name>' Use this command to view the Phase1 status for a specific tunnel.

Note:

'diagnose vpn ike gateway list' can also be executed to view the Phase1 status of all tunnels, needs to be run from the related VDOM.

When Phase1 is down:

When Phase1 is up:

Step 4: Analyze the IKE Phase 1 messages on the responder to identify a solution when Phase 1 is not up.

Troubleshooting the IKE Phase1 problem is best handled by reviewing VPN status messages on the responder firewall.
The responder is the 'receiver' side of the VPN, receiving tunnel setup requests.
The initiator is the side of the VPN that sends the initial tunnel setup requests.

Checklist:

Check if there is any other device upstream of the firewall.
Check if the VPN Gateway is configured to use the correct outgoing interface.
Check that the remote IP is configured correctly.
Run a packet capture on the outgoing interface and confirm it is possible to see traffic from the remote peer. If not:

Note:

Make sure that IKE traffic on port 500/4500 is allowed in the network device connected upstream.

Packet capture can be run from the CLI or the GUI:

In the GUI:

Note:

In v7.2 and v7.4, diagnostics are an option instead of packet capture under the network section. Select diagnostics and then select new packet capture.

CLI:

diagnose sniffer packet any 'host <remote-peer-ip> and port (500 or 4500)' 6 0 l

Use 'Ctrl + C' to stop the processes.

If it is possible to see traffic on port 500/4500, follow the steps below to troubleshoot this issue:
Run the following commands (on the receiver) to capture the IKE logs and initiate tunnel/traffic from the remote end, where 10.10.100.109 is the remote gateway:

diagnose debug console timestamp enable
diagnose vpn ike log-filter dst-addr4 10.10.100.109
diagnose debug application ike -1
diagnose debug enable

To disable debugs:

diagnose debug reset
diagnose debug disable

Note:

Starting from v7.4.1, the 'diagnose vpn ike log-filter dst-addr4' command has been changed to 'diagnose vpn ike log filter rem-addr4'.

To display the list of filters, use a '?' after 'filter'.

diagnose vpn ike log filter ?

loc-addr4:   IPv4 local gateway address range to filter by.
mloc-addr4:  Multiple IPv4 local gateway address to filter by.
rem-addr4:   IPv4 remote gateway address range to filter by.
mrem-addr4:  Multiple IPv4 remote gateway address to filter by.
loc-addr6:   IPv6 local gateway address range to filter by.
mloc-addr6:  Multiple IPv6 local gateway address to filter by.
rem-addr6:   IPv6 remote gateway address range to filter by.
mrem-addr6:  Multiple IPv6 remote gateway addresses to filter by.

diagnose vpn ike log filter rem-addr4 10.10.100.109
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable

To disable debug processes:

diagnose debug reset
diagnose debug disable

Note:

Try to run the packet capture and the logs at the same time.
If VDOMs are enabled, make sure to be in the VDOM context and then execute the above commands.

If there are more active tunnels on VDOM, it is possible to reduce a possibly large debug output with the following command (FortiOS v7.4.x) and filter the debugged tunnel by name, for example:

diagnose vpn ike log filter name <name of tunnel>

Note:

In some scenarios where the IPsec tunnel is failing to connect, even though both sides of the tunnel have matching config, running the IKE debug mentioned above may return indicators like the following:

ike 0:testvpn:testvpn: IPsec SA connect 5 x.x.x.y->x.x.x.x:0
ike 0:testvpn: ignoring request to establish IPsec SA, no policy configured

If the IKE logs above are displayed, make sure there is a policy configured for that tunnel interface.

Step 5: Phase1 has been established, but Phase2 is down.

Checklist:

Confirm if the Encryption and hash algorithms match on both the receiver and the initiator.
Check if PFS is enabled; if yes, make sure the configuration matches on both units.
Make sure that the quick mode selectors (interesting traffic) match on both units.
If Phase-2 is still not up, run the packet capture on port 500/4500 and run the following commands.

diagnose vpn ike gateway list

Or:

diagnose vpn ike gateway list name <tunnel-name>

Then, where 10.10.100.109 is the remote gateway:

diagnose vpn ike log-filter dst-addr4 10.10.100.109
diagnose debug console timestamp enable  
diagnose debug application ike -1
diagnose debug enable

To disable debugging:

diagnose debug reset
diagnose debug disable

In one scenario where the IPsec tunnel is failing to connect even though both sides of the tunnel have matching config, running the IKE debug mentioned above can give indicators like the following:

tunnel is administratively down

The above message indicates that the tunnel interface was disabled or turned down by the firewall administrator. To enable the tunnel interface from the GUI: go to Network -> Interfaces, select the tunnel interface and select 'edit', select the 'enable' button, and then save the change by selecting 'OK'.

This can be done from the CLI as well:

config system interface
    edit <tunnel name>
        set status up
    next
end

Note:

If VDOMs are enabled, make sure to be in the VDOM context and then execute the above commands.

Packet capture can be collected as shown below:

Step 6: Phase2 is up, but traffic is not passing.

Once the tunnel is up, traffic will be encapsulated in the ESP (Encapsulating Security Payload) protocol and sent to the remote peer.

Checklist:

Make sure the quick mode selector defined in Phase2 is configured properly to allow the traffic flow, which is having the issue.

For example:

Phase2, defined below, allows traffic between 192.168.1.0/24 and 192.168.2.0/24.

The IP address of the PC having an issue is 10.10.100.100/24.
If this PC is trying to reach any host in the 192.168.2.0/24 network, FortiGate will drop this traffic because the phase2 quick mode selector does not have this source network included in it.

Check that the IPv4 policies and routes are in place to confirm:

If there is a policy defined for this traffic flow.
If there are any source and destination addresses defined, make sure it is configured to allow this traffic flow.
If the routes are added correctly, pointing to the tunnel.
If the debug flow shows that the traffic is allowed but provides an error stating 'No matching IPsec selector, drop', check if NAT is enabled in the firewall policy for outbound IPsec VPN traffic. If it is, try to disable NAT in this firewall policy and test again.

In cases where ping is used as the diagnostic tool to test connectivity between local and remote sites, it will fail despite having the required firewall policy, phase 2 selectors (if defined), and static routes/blackhole routes configured on the FortiGate. However, when running the debug flow, it will show that the traffic is leaving the correct tunnel interface and gateway.
Ping to the FortiGate interface and the remote WAN interface works. To resolve this, check the Windows firewall settings on the destination devices to see whether it is enabled. This is a default behavior on the Windows firewall. To allow ICMP requests for testing connectivity, refer to these articles:
- Technical Tip: Unable to ping Windows Device from FortiGate
- Troubleshooting Tip: Windows 10 computer does not reply to ping
If the issue persists: Enable packet capture for the remote peer’s IP address and set the protocol to 50 (ESP).

Open two SSH sessions and run the following commands:

SSH session 1:

The value of 'proto' is optional, where 1=ICMP, 6 = TCP, 17 = UDP, etc.

diagnose debug console timestamp enable  
diagnose debug flow filter addr <destination-IP>
diagnose debug flow filter proto <1 or 17 or 6> 
diagnose debug flow show iprope enable
diagnose debug flow show function-name enable
diagnose debug flow trace start 1000

To disable debug commands:

diagnose debug reset
diagnose debug disable

Other protocol numbers can be used as well. For example, OSPF(89).

SSH Session 2:

diagnose vpn tunnel list

diagnose vpn tunnel list name <phase2_tunnel_name>

SSH Session 3:

To clear the session for the source and destination, use the following commands:

diagnose sys session filter clear
diagnose sys session filter src <source-IP>
diagnose sys session clear

diagnose sys session filter clear
diagnose sys session filter dst <destination-IP>
diagnose sys session clear

Note:

If VDOMs are enabled, make sure not to be in the VDOM context, and then execute the command above.

Make sure to collect packet capture and the logs mentioned above around the same time and attach them to the Fortinet case updates.

Along with this information, attach the network topology (if any).

With this information, TAC will try to decrypt the ESP traffic in Wireshark. If the remote peer is FortiGate as well, take a packet capture on this unit as well, which will make sure that this unit received the encrypted traffic, or if it was lost in the middle.

Note:

Under Dashboard -> IPsec Monitor, the number of encrypts and decrypts for the affected tunnel can be viewed. In case Encrypts are increasing and decrypts are not, this means that maybe the FortiGate is not receiving the return traffic. In case there are decrypts and no encrypts, this means that the FortiGate is receiving the traffic from the peer end; however, for some reason, the FortiGate is not sending the traffic out to its LAN, or the traffic is not received from the LAN.

There is a chance that both encrypt and decrypt are 0. In this case, first, it needs to be checked which side of the IPsec tunnel is initiating the traffic if the traffic is reaching the FortiGate, and if the firewall policies are in place.

Step 7: Troubleshoot the IPsec VPN that is flapping.

Checklist:

Check whether the issue affects one VPN or all configured VPNs. If all VPN tunnels are affected:

Check the Internet connection.
Run the following command to find errors/logs associated with the firewall/interface.
- Press Ctrl + C to stop 'diagnose sys top 2 50' (run it for 5 iterations).

diagnose debug crashlog read
diagnose sys top 2 50 
get system performance status
diagnose hardware sysinfo conserve
diagnose hardware deviceinfo nic <interface-name>  
execute tac report

Note:

If VDOMs are enabled, make sure not to be in the Global context and then execute the commands above.

If only one tunnel is flapping, collect the 'VPN Events' log as shown below:

Consider whether the VPN was stable for some time and is only now going up and down.
If so, investigate for network or unit changes or if any new network equipment has been added to the environment. If so, confirm changes/additions are correct.
Tunnel flaps can also occur due to a Dead Peer Detection (DPD) failure. In such a scenario, it is important to verify that the local-in policy should not block any DPD packets from the remote IPsec peer.
If not, collect logs and packet capture as mentioned in Step 4.

Make sure to collect packet captures and all the logs mentioned above around the same time and attach them to the Fortinet case updates. Along with this information, attach the network topology (if any). With this information, TAC will investigate this issue.

Step 8: Logs to be collected and attached to the TAC case.
Checklist:

SSH Session 1:

x.x.x.x is the remote gateway IP address.

diagnose debug console timestamp enable
diagnose vpn ike log filter rem-addr4 x.x.x.x  
diagnose debug application ike -1
diagnose debug enable

SSH session 2:

Press Ctrl + C to stop 'diagnose sys top 2 50' (run it for 5 iterations).

diagnose debug crashlog read
diagnose sys top 2 50             
get system performance status
diagnose hardware sysinfo conserve
diagnose hardware deviceinfo nic <interface-name>  
diagnose vpn ipsec status
diagnose vpn ike errors
diagnose vpn ike gateway list
diagnose vpn tunnel list
execute tac report

To disable debugs:

diagnose debug reset
diagnose debug disable

Packet capture: IKE Traffic on ports 500/4500.

Second Packet capture: ESP Traffic Protocol 50.

Note:

Some ISPs block traffic on port 500 if no ESP packets are being received, forcing NAT-T under phase1 -> network.

An ISP can block ESP packets even if the tunnel is up, as it can filter traffic based on the protocol number even after the tunnel is established.

To flush the tunnel, run the following:

diagnose vpn tunnel flush <phase1-name>
diagnose vpn ike gateway clear name <phase1-name>

Or:

diagnose vpn tunnel flush <phase1-name>
diagnose vpn ike gateway flush name <phase1-name>

FortiOS 8.0.1 and above enhances tunnel-down logging by providing clearer, more detailed log information to help administrators identify and troubleshoot IPsec tunnel failures faster. Refer to the doc for detail information :
Logging enhancements for tunnel down

Related articles:

Sign up

Login with SSO

Login to the community

Login with SSO