Configure IPsec Site-to-Site VPN on FortiGate
Detailed guide to configuring FortiGate IPsec site-to-site VPNs using custom settings, covering Phase 1/2 proposals, routing, and firewall policies.
Establishing secure, encrypted communication channels between geographically dispersed networks is a fundamental requirement for many organizations. IPsec site-to-site VPNs provide this capability, and FortiGate firewalls offer robust tools for their implementation. This article details the process of configuring an IPsec site-to-site VPN on a FortiGate, focusing on a custom configuration that allows for precise control over cryptographic parameters and network definitions.
The configuration assumes two FortiGate devices, FortiGate-A (local) and FortiGate-B (remote), acting as VPN peers. The local network is 10.10.1.0/24, and the remote network is 10.20.1.0/24. This guide focuses on configuring FortiGate-A; the configuration on FortiGate-B would be a mirror image.
Prerequisites
Before beginning the IPsec configuration, ensure the following:
- Both FortiGate devices have reachability to their respective public IP addresses from the internet.
- WAN interfaces are correctly configured with static or dynamic public IP addresses.
- UDP ports 500 (IKE) and 4500 (IPsec NAT-Traversal, if applicable) are allowed inbound on the WAN interfaces of both FortiGates from the peer's public IP.
- Administrative access to both FortiGate devices via GUI or CLI.
- FortiOS version 6.4 or 7.0 (minor syntax differences may exist in other versions, but the core concepts remain).
Phase 1: IKE Gateway Configuration (FortiGate-A)
Phase 1 establishes a secure, authenticated channel (the IKE SA) between the two FortiGate peers. We'll use the GUI's VPN → IPsec Wizard → Custom option for initial setup, then refine it.
GUI Wizard Initial Steps
- Navigate to VPN > IPsec Wizard.
- Select Site to Site > Custom and click Next.
- VPN Name:
VPN_to_FortiGate_B - Template Type:
Site to Site - Remote Device Type:
FortiGate - NAT Configuration:
No NAT between sites - Click Next.
- IPsec Gateway:
- IP Address:
1.1.1.1(FortiGate-A's WAN IP) - Interface:
wan1(Or your primary WAN interface) - Mode:
Main Mode(IKEv1) orIKEv2. For interoperability, IKEv1 Main Mode is often used, but IKEv2 is more robust. We'll use IKEv2 for this example. - Authentication:
Pre-shared Key - Pre-shared Key:
YourStrongSecretKey123!(Must match on both sides) - Peer Options:
Dialup User(If the remote peer has a dynamic IP) orStatic IP Address(If remote peer has a static IP). For this example, assume static IP. - Static IP Address:
2.2.2.2(FortiGate-B's WAN IP)
- IP Address:
- Click Next.
Refining Phase 1 Proposals (CLI)
The wizard often sets default proposals. For stronger security, we'll configure specific IKEv2 proposals via CLI. Navigate to VPN > IPsec Tunnels, select VPN_to_FortiGate_B, and click Edit. Expand Phase 1 Proposal.
- Encryption: Select
AES256 - Authentication: Select
SHA256 - Diffie-Hellman Group: Select
14(2048-bit MODP) - Key Lifetime:
86400seconds (24 hours)
Alternatively, via CLI for precise control:
config vpn ipsec phase1-interface
edit "VPN_to_FortiGate_B"
set interface "wan1"
set ip-version 4
set type static
set remote-gw 2.2.2.2
set psksecret YourStrongSecretKey123!
set proposal aes256-sha256
set dhgrp 14
set nattraversal enable
set remotegw-detect-interval 10
set keepalive 10
set keylife 86400
set peertype static
set ike-version 2
next
end
Note: nattraversal should be enabled if either peer is behind a NAT device. remotegw-detect-interval and keepalive help with tunnel stability.
Phase 2: IPsec SA Configuration (FortiGate-A)
Phase 2 establishes the IPsec Security Association (SA) that defines how user data will be encrypted, authenticated, and transmitted over the secure tunnel created in Phase 1.
Defining Local and Remote Subnets
The wizard will ask for local and remote network details. Enter these carefully:
- Local Address: Create a new address object for
10.10.1.0/24(e.g.,LAN_FortiGate_A). - Remote Address: Create a new address object for
10.20.1.0/24(e.g.,LAN_FortiGate_B).
Refining Phase 2 Proposals
In the Phase 2 Proposal section (accessed via VPN > IPsec Tunnels > VPN_to_FortiGate_B > Edit > Phase 2 Selectors):
- Name:
VPN_to_FortiGate_B_Phase2(auto-generated) - Local Address:
LAN_FortiGate_A(10.10.1.0/24) - Remote Address:
LAN_FortiGate_B(10.20.1.0/24) - Encryption: Select
AES256 - Authentication: Select
SHA256 - Enable Replay Detection:
Enabled(Recommended) - Enable Perfect Forward Secrecy (PFS):
Enabled(Recommended) - Diffie-Hellman Group: Select
14(Must match Phase 1's DH group if PFS is enabled) - Keylife:
3600seconds (1 hour)
CLI equivalent:
config vpn ipsec phase2-interface
edit "VPN_to_FortiGate_B_Phase2"
set phase1name "VPN_to_FortiGate_B"
set proposal aes256-sha256
set pfs enable
set dhgrp 14
set keylife-type seconds
set keylifeseconds 3600
set replay detect
set src-addr-type name
set dst-addr-type name
set src-name "LAN_FortiGate_A"
set dst-name "LAN_FortiGate_B"
next
end
Routing for the VPN Tunnel
Once the IPsec tunnel is defined, you need to tell the FortiGate how to reach the remote network through this tunnel. This is done with a static route pointing to the VPN interface.
Adding a Static Route (FortiGate-A)
- Navigate to Network > Static Routes.
- Click Create New.
- Destination:
10.20.1.0/24(LAN_FortiGate_Baddress object) - Device: Select the IPsec interface, which will be named something like
VPN_to_FortiGate_B. - Administrative Distance: Keep default (10).
- Click OK.
CLI equivalent:
config router static
edit 0
set dst 10.20.1.0 255.255.255.0
set device "VPN_to_FortiGate_B"
next
end
Firewall Policies
Even with the tunnel up and routing configured, traffic will not flow until firewall policies permit it. You need policies for both directions of traffic.
Creating Policies (FortiGate-A)
- Navigate to Policy & Objects > Firewall Policy.
- Click Create New.
- Policy 1 (Local to Remote):
- Name:
LAN_to_VPN_FortiGate_B - Incoming Interface:
internal(Your LAN interface) - Outgoing Interface:
VPN_to_FortiGate_B(The IPsec interface) - Source:
LAN_FortiGate_A(or specific hosts if needed) - Destination:
LAN_FortiGate_B(or specific hosts if needed) - Service:
ALL(or specific services likePING,HTTP,SSH) - Action:
ACCEPT - NAT:
Disable(Crucial for site-to-site VPNs where traffic should not be NAT'd) - Log Allowed Traffic:
All Sessions(Recommended for troubleshooting)
- Name:
- Click OK.
- Policy 2 (Remote to Local):
- Name:
VPN_FortiGate_B_to_LAN - Incoming Interface:
VPN_to_FortiGate_B - Outgoing Interface:
internal - Source:
LAN_FortiGate_B - Destination:
LAN_FortiGate_A - Service:
ALL - Action:
ACCEPT - NAT:
Disable - Log Allowed Traffic:
All Sessions
- Name:
- Click OK.
CLI equivalent for policies:
config firewall policy
edit 0
set name "LAN_to_VPN_FortiGate_B"
set srcintf "internal"
set dstintf "VPN_to_FortiGate_B"
set srcaddr "LAN_FortiGate_A"
set dstaddr "LAN_FortiGate_B"
set action accept
set schedule "always"
set service "ALL"
set nat disable
set logtraffic all
next
edit 0
set name "VPN_FortiGate_B_to_LAN"
set srcintf "VPN_to_FortiGate_B"
set dstintf "internal"
set srcaddr "LAN_FortiGate_B"
set dstaddr "LAN_FortiGate_A"
set action accept
set schedule "always"
set service "ALL"
set nat disable
set logtraffic all
next
end
Verification and Monitoring
After configuring both FortiGates, the tunnel should come up. You can verify its status:
- GUI: Navigate to VPN > IPsec Tunnels. The status icon next to
VPN_to_FortiGate_Bshould be green. Hover over it for more details. - CLI: Use the command
diagnose vpn ike gateway listto see Phase 1 status anddiagnose vpn ike tunnel listto see Phase 2 status. - Ping: From a host on
10.10.1.0/24, try pinging a host on10.20.1.0/24. - Traffic Logs: Check Log & Report > Traffic > Forward Traffic to see if sessions are being established through the VPN policies.
FortiGate-A # diagnose vpn ike gateway list
vpn_to_fortigate_b: FortiGate-A
... (truncated output)
IKEv2:established
... (truncated output)
FortiGate-A # diagnose vpn ike tunnel list
list all ipsec tunnel(s) in vd root:
name=VPN_to_FortiGate_B_Phase2(0) ver=2
sa_ip=1.1.1.1:500 sa_port=500 initiator_spi=c93d... responder_spi=51a8...
src_ip=10.10.1.0/24:0 dst_ip=10.20.1.0/24:0
... (truncated output)
Common Pitfalls
- Mismatched Pre-shared Keys: A frequent cause of Phase 1 failure. Double-check on both ends.
- Mismatched Proposals: Ensure Encryption, Authentication, and DH Group (for both Phase 1 and Phase 2, especially if PFS is enabled) match exactly on both peers.
- Incorrect Local/Remote Subnets: Phase 2 will not come up if the traffic selectors (local and remote subnets) are misconfigured or do not precisely match the traffic attempting to cross the tunnel.
- NAT Traversal Issues: If either FortiGate is behind a NAT device and its WAN interface IP is a private address, ensure
nattraversalis enabled, and UDP/4500 is open. - Firewall Policies: Forgetting to create policies or configuring them with NAT enabled (which should typically be disabled for site-to-site VPN traffic) will prevent traffic flow.
- Routing: Absence of a static route to the remote subnet via the IPsec interface is a common oversight.
- Aggressive Mode (IKEv1): If using IKEv1, Main Mode is generally preferred for site-to-site, but if one peer mandates Aggressive Mode, ensure both are configured accordingly, and be aware of its security implications (e.g., identity protected later).