FortiGate to SonicWall IPsec VPN behind NAT: a field guide

Cross-vendor site-to-site VPNs are routine until one side sits behind carrier NAT. Then tunnels refuse to establish, or come up and drop. This guide covers the settings that most often cause trouble between FortiGate and SonicWall, based on a tunnel we stabilised for a multi-site network.

The topology

One site runs a FortiGate behind an ISP router that performs NAT, so the firewall's WAN interface holds a private address. The other site runs a SonicWall with a static public IP. The FortiGate is the sole initiator, because the SonicWall cannot reach it directly through the ISP NAT.

Phase 1 and phase 2 parameters

Start with matching, modern parameters on both sides:

• IKE version 2
• Encryption AES-256, integrity SHA-256
• Diffie-Hellman group 14
• Phase 1 lifetime 28800 seconds, phase 2 lifetime 3600 seconds
• NAT traversal enabled

Problem 1: the local ID

By default, a FortiGate behind NAT identifies itself using its private WAN address. The SonicWall expects the peer's public IP as the remote IKE ID, so authentication fails with an identity mismatch.

The fix is to set the FortiGate's local ID explicitly to its public IP, and set the ID type to address. In FortiOS, set localid before localid-type, otherwise the configuration check can fail:

config vpn ipsec phase1-interface
    edit "to-sonicwall"
        set localid "<fortigate-public-ip>"
        set localid-type address
    next
end

On the SonicWall, the remote IKE ID must match exactly the value configured as the FortiGate's local ID.

Problem 2: perfect forward secrecy mismatch

FortiOS enables PFS in phase 2 by default. If the SonicWall policy has PFS turned off, phase 1 succeeds but phase 2 negotiation fails. Either enable PFS with the same DH group on both sides, or disable it on the FortiGate to match:

config vpn ipsec phase2-interface
    edit "to-sonicwall-p2"
        set pfs disable
    next
end

Matching is what matters. If your security policy requires PFS, enable it on the SonicWall instead.

Problem 3: dead peer detection

Aggressive DPD settings combined with NAT timeouts can cause the tunnel to flap. Setting DPD to on-demand on the FortiGate side produced a stable tunnel in our case.

When the ISP changes your public IP

If the NAT'd site has a dynamic public IP, every change breaks the tunnel. You must update three things together: the SonicWall gateway address, the SonicWall remote IKE ID and the FortiGate local ID. A more durable approach is to use an FQDN with dynamic DNS for both the gateway and the IKE identity.

Troubleshooting checklist

1. Confirm both sides use the same IKE version and proposals.
2. Check the local and remote IKE IDs match exactly.
3. Align PFS and DH groups for phase 2.
4. Ensure NAT traversal is enabled and UDP 500 and 4500 are allowed.
5. Verify phase 2 selectors match each side's LAN subnets.
6. Review DPD and keep-alive settings.
7. Use IKE debug logs on the FortiGate and VPN logs on the SonicWall side by side.

Need help with a multi-vendor network? Our network security team builds and supports cross-vendor connectivity every week.