Stackvora.tech

Troubleshoot a Down IPsec Tunnel on FortiGate

Establishing and maintaining IPsec VPN tunnels is a fundamental task for securing site-to-site connectivity. However, these tunnels can intermittently…

Establishing and maintaining IPsec VPN tunnels is a fundamental task for securing site-to-site connectivity. However, these tunnels can intermittently fail due to various factors, ranging from misconfigurations to network path issues. This article provides a systematic approach to diagnosing and resolving common issues when an IPsec tunnel goes down on a FortiGate firewall, focusing on practical commands and log analysis.

We will cover Phase 1 (IKE) and Phase 2 (IPsec) troubleshooting, delve into useful diagnostic commands, and discuss common configuration pitfalls.

Initial Verification and Status Checks

Before diving deep into logs, perform basic checks to confirm the tunnel's state and identify any immediate issues. This ensures the tunnel is indeed "down" from the FortiGate's perspective and helps narrow down the problem scope.

Check Tunnel Status from GUI and CLI

The FortiGate GUI provides a quick overview. Navigate to VPN > IPsec Tunnels and observe the tunnel's status icon. A red "down" arrow confirms the issue. For a more detailed view:

diagnose vpn tunnel list name <tunnel_name>

Replace <tunnel_name> with the exact name of your IPsec tunnel. Look for the "Status" field. If it shows "down" or "not established," proceed. If the tunnel shows "up" but traffic isn't passing, the issue might be routing or security policies, which we'll touch upon later.

Ping Local and Remote Peers

Verify basic IP connectivity between the FortiGate and the remote IPsec peer. This rules out fundamental network path failures (e.g., routing, ISP issues).

execute ping <remote_gateway_ip>
execute traceroute <remote_gateway_ip>

Ensure the FortiGate can reach the remote gateway. If ping fails, investigate upstream network issues before troubleshooting IPsec.

Phase 1 (IKE) Troubleshooting

Phase 1, also known as the Internet Key Exchange (IKE) phase, is responsible for establishing a secure channel (IKE SA) to negotiate Phase 2 parameters. If Phase 1 fails, Phase 2 cannot proceed.

Confirm Phase 1 Status with diagnose vpn ike gateway list

This command provides critical insight into the IKE negotiation status.

diagnose vpn ike gateway list name <tunnel_name>

Look for the "status" field. If it reads "established," Phase 1 is up. If it's "down," "initiator," or "responder" (and not progressing), then Phase 1 is failing. Pay attention to "reconnect time" and "rekey time" values which indicate successful negotiations or attempts.

Common Phase 1 Mismatches and Checks

The most frequent culprits for Phase 1 failures are parameter mismatches:

  • Pre-shared Key (PSK): This must be identical on both VPN peers, including case sensitivity. This is often the first thing to check.
  • IKE Version: Ensure both sides are configured for IKEv1 or IKEv2. FortiGates default to IKEv1 on older firmware and IKEv2 on newer (e.g., FortiOS 6.4+ when creating new tunnels, but often support both).
  • Authentication Method: Typically Pre-shared Key. Certificates are less common for basic site-to-site but must match if used.
  • DH Group (Diffie-Hellman): Both sides must use the same DH group (e.g., Group 5). Higher groups offer better security but require more CPU.
  • Encryption and Authentication Algorithms: These define the encryption and hashing for the IKE SA (e.g., AES256 / SHA256). The algorithms must overlap and match. Ensure the remote side's *preferred* algorithms are included in your FortiGate's proposals. FortiGate often allows multiple proposals.
  • Local/Remote Gateway IP Addresses: The remote gateway IP configured on your FortiGate must be the public IP of the remote VPN device, and vice-versa. A common mistake is using an internal IP.
  • NAT Traversal (NAT-T): If either VPN peer is behind a NAT device, NAT-T must be enabled on both sides. FortiGate typically enables this by default for IKEv1 if NAT is detected. For IKEv2, NAT-T is implicitly supported. UDP port 4500 is used for NAT-T.
  • Local ID: If configured (especially for IKEv2), the Local ID on one side must match the Remote ID on the other. This is often the FortiGate's WAN IP or a FQDN.

Using Debug Logs for Phase 1

The diagnose debug application ike command is indispensable for real-time IKE negotiation analysis.

diagnose debug reset
diagnose debug application ike -1
diagnose debug enable
execute vpn ipsec tunnel status down <tunnel_name>  <-- Bring down the tunnel to force re-negotiation
execute vpn ipsec tunnel status up <tunnel_name>    <-- Bring up the tunnel
diagnose debug disable
diagnose debug reset

Analyze the output carefully. Look for messages indicating "no proposal chosen," "malformed packet," "authentication failed," "peer negotiation failed." These messages directly point to parameter mismatches.

Example of a PSK mismatch:

ike 0: <tunnel_name>:492: PSK authentication failed.
ike 0: <tunnel_name>:492: Peer's SA proposal for Phase 1 is not acceptable.

Phase 2 (IPsec) Troubleshooting

Once Phase 1 is established, Phase 2 (IPsec SA) is negotiated to define how user data will be encrypted and authenticated. If Phase 2 fails, you'll see Phase 1 up, but no traffic will flow through the tunnel.

Confirm Phase 2 Status

diagnose vpn tunnel list name <tunnel_name>

If Phase 1 is established but Phase 2 isn't, this command will show "up" for the IKE SA but no active IPsec SAs. You can also use:

diagnose vpn ike gateway list name <tunnel_name>

This will show "established" for IKE. To see the specific Phase 2 SAs:

diagnose vpn ike tunnel list name <tunnel_name>

Look for active "selectors" and "SPI" values, indicating successful Phase 2 establishment. If these are missing or show 0 bytes, Phase 2 is likely the problem.

Common Phase 2 Mismatches and Checks

  • Phase 2 Selectors (Local/Remote Subnets): This is arguably the most common Phase 2 failure point. The local subnets defined on one side must exactly match the remote subnets defined on the other, and vice-versa. For example, if FortiGate has local 10.1.0.0/24 and remote 192.168.1.0/24, the peer must have local 192.168.1.0/24 and remote 10.1.0.0/24. Do not overlap or use /32 for a whole subnet.
  • PFS (Perfect Forward Secrecy): If enabled on one side, it must be enabled on the other, and use a matching DH group. If it's disabled on one side, it must be disabled on the other.
  • Encryption and Authentication Algorithms: Similar to Phase 1, the algorithms (e.g., AES256 / SHA256) for the IPsec SA must match and overlap.
  • Lifetime: The SA lifetime (e.g., 3600 seconds) should ideally match, though slight differences are usually tolerated as long as rekeying works.
  • Autokey Keep Alive: This FortiGate setting (set auto-discovery-sender enable or via GUI) ensures the FortiGate keeps the tunnel up even without traffic. If disabled, the tunnel might only come up on demand.

Using Debug Logs for Phase 2

The same IKE debug command also captures Phase 2 negotiation details.

diagnose debug reset
diagnose debug application ike -1
diagnose debug enable
execute vpn ipsec manual-key clear <tunnel_name> <-- Use this to clear existing Phase 2 SAs
execute vpn ipsec tunnel status down <tunnel_name>
execute vpn ipsec tunnel status up <tunnel_name>
diagnose debug disable
diagnose debug reset

Look for messages like "no policy found," "no acceptable proposal," "selector payload mismatch." These indicate issues with the local/remote subnets or the Phase 2 proposal parameters.

Example of a selector mismatch:

ike 0: <tunnel_name>: IPsec SA selectors do not match the policy.
ike 0: <tunnel_name>: Peer proposal for Phase 2 not acceptable.

Network and Policy Considerations

Even if both Phase 1 and Phase 2 establish successfully, traffic might still not pass. This points to routing or security policy issues.

Routing

Ensure that the FortiGate has a static route (or dynamic route via OSPF/BGP if configured) pointing to the remote subnet via the IPsec tunnel interface. The "interface" for the route should be the VPN tunnel name itself.

config router static
    edit 0
        set dst <remote_subnet> <remote_subnet_mask>
        set device <tunnel_name>
    next
end

Verify the route table:

get router info routing-table details

Confirm there's an active route (e.g., "S*" for static) for the remote subnet via the VPN interface.

Firewall Policies

You need firewall policies to allow traffic to and from the IPsec tunnel. Create policies for both directions:

  • Internal to VPN: Source interface (internal LAN), Destination interface (VPN tunnel name), Source address (local subnet), Destination address (remote subnet), Service (any or specific).
  • VPN to Internal: Source interface (VPN tunnel name), Destination interface (internal LAN), Source address (remote subnet), Destination address (local subnet), Service (any or specific).

Ensure NAT is disabled on these policies unless explicitly required (e.g., NAT-T is different from policy-based NAT). For standard site-to-site IPsec, NAT should usually be disabled on the VPN policies.

Check policy hits with:

diagnose firewall proute list

This shows if traffic is hitting the expected policy. If traffic hits a different policy (e.g., the default internet access policy), your VPN policy order or matching criteria might be incorrect.

Common Pitfalls

  • Firmware Version Inconsistencies: While IPsec standards aim for interoperability, different FortiOS versions or different vendor implementations can have subtle differences. Ensure both sides are using reasonably modern and patched firmware.
  • Aggressive Mode (IKEv1): While often supported, Main Mode is generally preferred for security and compatibility. If using Aggressive Mode, Local ID is usually mandatory.
  • Dead Peer Detection (DPD): If DPD is too aggressive or not configured similarly on both sides, it can cause unnecessary tunnel flapping. Review set dpd <on-demand|on-idle> and set dpd-retryinterval.
  • Tunnel Interface vs. Policy-based VPN: FortiGate offers both. Most modern deployments use route-based (tunnel interface) VPNs, which require static routes and policy configuration as described. Policy-based VPNs define selectors directly in the phase2-interface. Ensure you're consistent.
  • Overlapping Subnets: If local and remote subnets overlap, traffic will never correctly route through the VPN.
  • Hardware Offloading: In high-performance scenarios, NPUs might offload IPsec. While rare, a bug could impact tunnel stability. Consult release notes for known issues.
  • Time Skew: Significant time differences between peers can affect certificate-based authentication and logging accuracy, though less common with PSK.

Back to the knowledge base · Ask the AI assistant