pjhtech Tools
FortiGate

FortiGate IKEv1 to IKEv2 Site-to-Site Migration

Convert an existing route-based FortiGate tunnel to IKEv2: phase 1 changes, peer IDs, Child SA selectors and common negotiation failures.

To migrate an existing site-to-site tunnel to IKEv2, set ike-version 2 on both peers’ existing phase 1 objects. Keep the tunnel names, routes, firewall policies and protected networks. The peers will renegotiate, interrupting the tunnel.

Scope: FortiGate static gateway-to-gateway IPsec. FortiClient dial-up authentication is covered separately.

Read the current tunnel at both peers

In the VDOM that owns the tunnel, save the following output privately before the change. Replace the tunnel name with its existing name at each site.

Read-only • run in the tunnel’s VDOM
show full-configuration vpn ipsec phase1-interface "<existing-tunnel>"
show full-configuration vpn ipsec phase2-interface

In phase 1, record ike-version, interface, remote-gw, authmethod, proposal, dhgrp, localid and peerid/peertype. In phase 2, select only entries whose phase1name matches this tunnel; record their proposals, PFS/group and src-subnet/dst-subnet or named selectors. Full configuration includes defaults as well as encrypted secrets.

With VDOMs enabled, a global administrator enters the existing context using config vdom then edit "<existing-vdom>"; stay in that context for the tunnel commands and use end when finished. A VDOM administrator is already in the assigned VDOM.

Keep selectors and authentication compatible

Selectors reverse at the opposite peer: A’s local network is B’s remote network. Preserve explicit subnet, protocol and port selectors where used. Replacing them with 0.0.0.0/0 changes the agreement rather than converting it.

IKEv2 has no Main/Aggressive Mode or IKEv1 XAuth. EAP belongs to user-authenticated remote access; leave it out of a PSK site-to-site migration.

Change the existing phase 1 object

Use the existing tunnel name so route and policy references stay attached to the same interface. The example changes only the IKE version; apply any agreed proposal or identity edits separately. Expect a tunnel interruption while the peers renegotiate.

Configuration change • replace the placeholder with the existing tunnel name
config vpn ipsec phase1-interface
    edit "<existing-tunnel>"
        set ike-version 2
    next
end

Use the failed stage to choose the next check

ResultNext check
IKE negotiation failsPeer address/ID and phase 1 proposals; inspect IKE debug
IKE SA forms but Child SA failsPhase 2 proposals, PFS and reversed selector pairs
Child SA forms but one subnet failsRoute, policy, NAT and return path for that subnet
Initial traffic works; later rekey failsRekey exchange and PFS/DH agreement

After changing both peers, start a new connection from a client covered by each selector pair and read the SA state:

Read-only • run in the tunnel’s VDOM
diagnose vpn ike gateway list
diagnose vpn tunnel list name <existing-tunnel>

Find the tunnel’s name and version: 2 in the gateway output, with IKE SA status: established. In the tunnel output, find the expected proxyid, its src/dst and a nonzero sa count; compare enc:pkts/bytes and dec:pkts/bytes before and after the client test. Keep this output private because it can include keys. A firewall-originated ping can use an address outside those selectors. If reverting the migration, restore the saved IKE/proposal/ID values on both peers; reversing only one side leaves the tunnel incompatible.

References