Technical Tip: Importance of using Static IP, FQDN or DDNS in IPsec dial-up VPN configurations

[montyadams]

Description	This article describes why a static public IP, FQDN, or DDNS hostname should be used as the remote gateway reference when configuring IPsec dial-in VPN tunnels on FortiGate. A stable identifier improves peer matching, strengthens security, and prevents tunnel instability when the remote peer’s public IP changes.
Scope	FortiGate, FortiOS v7.2.x and later.
Solution	In IPsec dial-in deployments, FortiGate must reliably associate an incoming negotiation with the correct Phase 1 configuration. Using a predictable remote gateway reference (static IP / FQDN / DDNS) and an explicit peer identifier (when applicable) helps prevent negotiation failures, policy mismatches, and intermittent tunnel drops caused by changing ISP-assigned addresses. Why it matters: Consistent peer matching: Ensures the correct Phase 1 is selected—especially important when multiple dial-in peers/tunnels exist. Stronger security controls: Reduces the chance of accepting negotiations from unintended peers by validating expected identifiers. Stable connectivity: Avoids outages when the remote peer’s public IP changes (typical with dynamic ISP links). Cleaner operations and troubleshooting: More accurate logs, monitoring, and diagnostics when endpoints are consistently identifiable. Configuration best practices: Configure remote-gw using a static IP, FQDN, or DDNS hostname. If using DDNS, confirm DNS resolution is reachable from FortiGate and that the DDNS record updates promptly after WAN IP changes. When operating in Aggressive mode, use peerid to enforce an expected peer identifier. For details on peerid and localID, refer to: Technical Tip: Use of PeerID and LocalID in IPsec VPN. Avoid overlapping internal subnets between VPN peers. If overlap is required, use NAT/overlap techniques as described here: Site-to-site VPN with overlapping subnets. Example CLI configuration (dial-in / dynamic peer): config vpn ipsec phase1-interface edit "dialin-vpn" set type dynamic set interface "wan1" set peertype any set mode aggressive set proposal aes256-sha256 set dhgrp 14 set remote-gw ddns.example.com set peerid "branch1" set psksecret ENC <encrypted_pre_shared_key> next end Additional recommendations: For environments with multiple dial-in peers, define unique peerid values to prevent matching ambiguity. If relying on DDNS/FQDN for peer identification, validate DNS behavior during failover events (e.g., WAN link changes) so the resolved address stays current. Related documents Configuring dynamic DNS Technical Tip: Troubleshooting IPsec dial-up VPN connections

[emmanuelgonzalez914]

Nice article