FortiGate Behind NAT: local-gw, localid and the Public IP

A FortiGate behind NAT can own 10.0.0.2 on its WAN interface while the internet presents it as 198.51.100.40, and both numbers are real. The address the device binds to and the identity it sends during IKE authentication are separate choices, made in separate fields, for separate audiences. NAT rewrites the outer addressing on the way past; it does not rewrite an authenticated identity into whatever the far peer expects. Most phase 1 failures in this shape come from putting the right value in the wrong field.

Three values, three owners

Start by naming the three values and who owns each. local-gw is the address the FortiGate uses to source IKE on its external interface, and it must be an address the device actually holds. The public endpoint is the NAT device's address, owned by whatever performs the translation. The IKE identity is a string the peer matches against its own configuration, and it is not required to be an IP address at all.

The field names are close enough to invite substitution, and that is the trap. localid and localid-type describe identification; local-gw describes local binding.

A walkthrough makes the distinction concrete. On the FortiGate, open config vpn ipsec phase1-interface, then set interface "wan1" and set local-gw 10.0.0.2 — an address the box owns, which is what makes the IKE socket bind successfully. Leave local-gw at 0.0.0.0 and the interface address is used, which is usually the same thing but less explicit. Do not set local-gw to 198.51.100.40, because the device does not own that address and the socket will not bind to it. Making two values look equal on paper is not a configuration.

Step 1: pick the identity the peer will accept

Now the identity, which is a different decision. set localid takes the value the peer will compare, and set localid-type tells the FortiGate how to interpret it: an address, an FQDN, a user FQDN or a key ID. With auto the device derives it, typically from the outgoing interface address, which is exactly the value a NAT device is about to change.

That derivation is why an explicit identity matters in this topology. If the peer expects an address identity, set localid-type address and localid to the public address the peer will observe, then confirm the peer accepts that value as an identity rather than as a routing target. If the peer expects an FQDN, use localid-type fqdn and the name it was configured with. Verify what was actually sent with diagnose vpn ike gateway list, which shows the gateway state and the identifiers in use rather than what you intended to type. Do not assume an identity-type option accepts an arbitrary non-local address; check the release's documented semantics first.

Step 2: forward UDP 500 and 4500 to the device

The third value belongs to the NAT device, and it is the one people forget to check. The public endpoint has to forward UDP 500 and UDP 4500 to the FortiGate, because NAT-T detection and the encapsulated ESP that follows both depend on those ports arriving. A one-to-one mapping is what this design assumes; port-based sharing of a single public address across several peers is a different topology with different limits.

Confirm the forwarding with a capture rather than a hope: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 shows whether packets are arriving and whether replies are leaving.

Google Cloud VPN documents one-to-one NAT with NAT-T as the supported arrangement for a peer behind NAT, and that is the constraint to design against if the far end is a Cloud VPN gateway. One-to-many or port-based sharing is not the same supported topology, and no amount of local identity tuning changes that. If the far side is another appliance, its own documentation defines what it will accept as an identity and whether it tolerates a translated peer address. Read that before changing a local field, because the local side cannot negotiate a rule the remote side does not implement.

Step 3: check what phase 1 does not solve

NAT traversal gets the tunnel up, identity agreement decides whether the peer accepts it, and inner prefix routing decides what actually crosses. A correct local ID cannot supply a missing static route or a missing traffic selector.

So verify in layers. get vpn ipsec tunnel details shows whether the tunnel is up and which selectors were negotiated, and a mismatch between the configured remote subnet and the negotiated selector is a routing problem wearing a phase 2 costume. execute vpn ike gateway clear forces a renegotiation, so you are testing the current configuration rather than a session established before your last change. Then send traffic to a host in the remote prefix and confirm the counters move, because a tunnel that is up and passing nothing looks identical to a working one until you check.

Keep the three values in one place in your notes: the local address the device owns, the public endpoint the NAT device presents, and the identity string the peer expects. They change for different reasons and at different times.

A NAT device renumbering is not a reason to touch the FortiGate's local-gw, and an identity change is not a reason to renumber anything. Mixing the two is how a working tunnel gets rebuilt during an unrelated maintenance window. The Cloud VPN NAT guidance is the reference for the supported topology on that side.

The test that settles it is boring and fast: capture on the external interface, confirm UDP 500 and 4500 arrive from the peer, confirm the identity in the IKE exchange matches what the peer was configured to expect, then confirm the negotiated selectors cover the subnets you care about. If the first check fails, the NAT device is the suspect. If the second fails, the identity fields are. If the third fails, neither NAT nor identity was ever the problem.