| Description |
This article describes how to configure Local ID on spoke FortiGate devices to match its hostname in a Dialup Hub-and-spoke IPsec VPN setup. This can assist an administrator to identify each spoke during troubleshooting, especially when multiple dial-up tunnels are active. |
| Scope | FortiGate, IKEv2 Hub-and-Spoke VPN. |
| Solution |
In IKEv2, Local ID and Peer ID are not used to differentiate different dialup gateways on the hub. Instead, the proprietary attribute 'network-id' is exchanged early in IKE negotiation to match the intended gateway. See the article Technical Tip: FortiGate Hub with multiple IPSec Dial-up phase1 using IKEv2 and PSK authentication for how this is configured.
Because setting the same Local ID for each spoke is not necessary in IKEv2, this field can be used to carry spoke-specific information such as hostname or site name if the remote authentication method is preshared key. Note: if certificates are used to authenticate spokes, the Peer ID field on the Hub will display the certificate's CN. See FortiOS v7.6.4 Administration Guide | Dialup IPsec VPN with certificate authentication for an example of this in the remote access use case.
Before using applying specific Local ID on each spoke, an IPsec Monitor on Hub FortiGate will show spokes coming in with different public IPs, but the Peer ID will typically be either a peer address or a generic configured value. It can be difficult to quickly identify which tunnel connection matches which spoke.
Hub configuration:
config vpn ipsec phase1-interface edit "HUB_ISP1" set type dynamic set peertype any set network-overlay enable set network-id 10 set localid "HUB_ISP1" next end
Spoke configuration:
config vpn ipsec phase1-interface edit "to_HUB_ISP1" set network-overlay enable set network-id 10 set localid "USA" next end
While Network ID is used to match the connection attempt to the appropriate dialup gateway, IKEv2 still exchanges and logs the peer identifiers.
Spoke IKE debugs:
ike V=root:0:spoke:7704: initiator received AUTH msg ike V=root:0:spoke:7704: received peer identifier FQDN 'HUB' ike V=root:0:spoke:7704: auth verify done ike V=root:0:spoke:7704: initiator AUTH continuation ike V=root:0:spoke:7704: authentication succeeded
Hub IKE debugs:
ike V=root:0:HUB:60801: responder received AUTH msg ike V=root:0:HUB:60801: processing notify type INITIAL_CONTACT ike V=root:0:HUB:60801: processing notify type MESSAGE_ID_SYNC_SUPPORTED ike V=root:0:HUB:60801: received peer identifier FQDN 'USA' ike V=root:0:HUB:60801: re-validate gw ID ike V=root:0:HUB:60801: gw validation OK ike V=root:0:HUB:60801: auth verify done ike V=root:0:HUB:60801: responder AUTH continuation ike V=root:0:HUB:60801: authentication succeeded
On IPsec monitor on the hub, the associated spoke's Local ID is displayed as Peer ID on the Hub. This allows easy identification of each spoke during monitoring and troubleshooting.
IKEv1:
A similar configuration can be used for some IKEv1 Hub and Spoke deployments, but note that FortiOS IKEv1 does not support network-id.
Peer ID/Local ID is sometimes used to differentiate multiple IKEv1 dial-up gateways configured on the same Hub interface, as demonstrated in Technical Tip: How to use Peer IDs to select an IPsec dialup tunnel on a FortiGate configured with m.... When configured in this way, Local ID is not available to convey spoke-specific information. |
