IPsec Site-to-Site VPN Tunnel Configuration Guide for FortiGate
A practical guide to secure HQ-to-branch connectivity using IKEv2, AES-256, Phase 1, Phase 2, firewall policies, dual ISP, and VPN troubleshooting.
LearnCyber.in | Network Security | FortiGate Configuration
A site-to-site Virtual Private Network (VPN) securely connects networks in different physical locations through an untrusted network such as the public internet. Organizations use site-to-site VPNs to connect headquarters, branch offices, data centers, cloud environments, and remote facilities without sending private network traffic as ordinary unencrypted internet traffic.
This guide explains the IPsec site-to-site VPN tunnel configuration shown in the infographic. The example uses two FortiGate firewalls, an HQ LAN, a branch LAN, public WAN addresses, IKEv2, AES-256 encryption, SHA-256 authentication, Diffie-Hellman Group 14, Perfect Forward Secrecy (PFS), and firewall policies that permit selected traffic through the encrypted tunnel.
The guide also covers Phase 1 and Phase 2 negotiation, network selectors, routing, NAT considerations, dual-ISP resilience, security monitoring, common errors, and a final validation checklist.
- How an IPsec site-to-site VPN works.
- How IKE Phase 1 differs from Phase 2.
- How to plan the HQ and branch networks.
- How to configure matching VPN proposals and mirrored selectors.
- How firewall policies, routes, and NAT affect VPN traffic.
- How to test and troubleshoot the encrypted tunnel.
- How to plan secure dual-ISP failover and monitoring.
1. What Is an IPsec Site-to-Site VPN?
IPsec stands for Internet Protocol Security. It is a suite of protocols used to protect IP traffic through authentication, integrity protection, and encryption according to the selected security configuration.
A site-to-site VPN establishes a secure connection between VPN gateways, commonly firewalls or routers. Devices on each site's private network can then communicate through the tunnel when routing, firewall rules, and VPN traffic selectors permit the communication.
1.1 Example: headquarters and branch office
Imagine a company with an office at headquarters and a second office in another city. The HQ network uses the subnet 10.10.1.0/24, while the branch network uses 10.20.1.0/24.
Without a VPN, the sites would need another approved private connectivity solution or a suitable secure tunnel to exchange private traffic over the internet. With a correctly configured site-to-site IPsec VPN, authorized traffic can travel between the two private networks inside an encrypted tunnel.
↓
FortiGate HQ
↓
Encrypted IPsec tunnel over the internet
↓
FortiGate Branch
↓
Branch LAN: 10.20.1.0/24
1.2 What does the tunnel protect?
- Confidentiality: Encryption helps prevent unauthorized parties from reading protected traffic.
- Integrity: Integrity protection helps detect unauthorized modification of protected packets.
- Peer authentication: The gateways authenticate each other using the configured method, such as a pre-shared key or certificates.
- Network connectivity: Authorized systems can communicate between private networks without exposing every internal service directly to the internet.
A VPN does not automatically make every connected endpoint trustworthy. Malware, compromised user accounts, overly permissive firewall rules, and vulnerable internal services can still create risk. The tunnel should be combined with access controls, endpoint protection, monitoring, and appropriate network segmentation.
2. Understanding the VPN Topology
The infographic shows two FortiGate firewalls connected through the public internet. Each firewall has a WAN interface connected to its internet service and a LAN interface serving its local network.
2.1 Network addressing plan
| Component | Example value |
|---|---|
| HQ FortiGate | FortiGate-1 |
| HQ public WAN IP shown | 203.0.113.1 |
| HQ LAN subnet | 10.10.1.0/24 |
| HQ example hosts | 10.10.1.10–10.10.1.12 |
| Branch FortiGate | FortiGate-2 |
| Branch public WAN IP shown | 203.0.113.2 |
| Branch LAN subnet | 10.20.1.0/24 |
| Branch example hosts | 10.20.1.10–10.20.1.12 |
| IKE version | IKEv2 |
| Phase 1 encryption | AES-256 |
| Authentication/integrity shown | SHA-256 |
| Diffie-Hellman group | Group 14 |
Addressing clarification: The addresses 203.0.113.0/24 and 198.51.100.0/24 are reserved for documentation examples. They are useful in diagrams and lab instructions but are not normal public production addresses. Use the actual WAN addresses assigned by the ISP in a real deployment.
2.2 Keep the private subnets distinct
The HQ and branch LANs must be routable without unintended overlap. In this example, 10.10.1.0/24 and 10.20.1.0/24 are different subnets, so each site can distinguish its own traffic from traffic destined for the other site.
If both sites use the same private subnet, ordinary routing and VPN selectors can become ambiguous. Overlapping networks require an explicitly designed solution, such as address translation or subnet renumbering, rather than simply copying this example.
2.3 Check the upstream internet connection
Before configuring the VPN, confirm that each firewall has a working WAN connection, a valid default route, correct DNS settings if hostnames are used, and an appropriate upstream policy. Confirm whether either firewall is behind another NAT device.
IPsec commonly uses UDP port 500 for IKE negotiation and UDP port 4500 when NAT Traversal is used. Native ESP uses IP protocol 50 where applicable. The exact path depends on the deployment and NAT conditions. Firewalls between the peers must permit the required traffic.
3. IKE Phase 1: Establishing the Secure Control Channel
Phase 1 establishes the IKE Security Association (IKE SA) between the two VPN gateways. The gateways negotiate compatible cryptographic parameters and authenticate each other before setting up the IPsec protection for user traffic.
3.1 Phase 1 parameters in the infographic
| Setting | Example | Purpose |
|---|---|---|
| Interface | WAN1 | Local internet-facing interface. |
| IKE version | 2 | IKEv2 negotiation. |
| Encryption | AES-256 | Protects the negotiated IKE traffic. |
| Authentication/integrity | SHA-256 | Represents the hash/integrity selection shown; exact proposal syntax varies by FortiOS version. |
| DH group | 14 | Diffie-Hellman key exchange group. |
| Key lifetime | 28,800 seconds | Illustrated IKE SA lifetime. |
| Authentication method | Pre-shared key | A shared secret known to both peers. |
The same compatible Phase 1 proposal and authentication method must be configured on both gateways. The local interface and remote peer address will differ because the devices are at opposite ends of the tunnel.
3.2 Use a strong pre-shared key
The infographic displays an example key for illustration. Do not use that string in a real environment. Generate a unique, high-entropy secret, protect it in an approved secrets manager, and avoid sharing it through tickets, screenshots, or unsecured messages.
For larger deployments, certificate-based authentication may be preferable because it avoids managing the same manually distributed secret across every peer. Select the method that fits the organization's security policy and operational capabilities.
3.3 What happens if Phase 1 fails?
If Phase 1 cannot be established, the gateways may disagree on the IKE version, encryption or integrity proposal, DH group, authentication method, peer address, or credentials. A blocked UDP 500/4500 path or incorrect upstream routing can also prevent negotiation.
Check the IKE logs and compare both peers' settings before changing unrelated LAN routing or firewall rules.
4. IKE Phase 2: Protecting the LAN-to-LAN Traffic
Phase 2 negotiates the IPsec Security Association (Child SA) used to protect the actual data traffic. It defines the traffic selectors, encryption and integrity settings, PFS behavior where configured, and lifetime for the protected traffic.
4.1 Correct network selectors
For the topology in this guide, the intended traffic selectors are:
HQ Phase 2
Local subnet: 10.10.1.0/24
Remote subnet: 10.20.1.0/24
Branch Phase 2
Local subnet: 10.20.1.0/24
Remote subnet: 10.10.1.0/24
Correction to the infographic: The branch Phase 2 panel appears to show the HQ subnet as its source and the branch subnet as its destination. For this conventional site-to-site design, those selectors should be reversed at the branch. Both peers must agree on the same protected traffic in opposite directions. Fortinet notes that only traffic matching the configured Phase 2 selectors can pass through the IPsec tunnel.
4.2 Phase 2 settings
- Encryption: AES-256, as shown in the infographic.
- Integrity: SHA-256 where used by the selected proposal.
- PFS: Enabled in the illustrated configuration.
- DH group: The configured PFS group must be compatible at both ends.
- Lifetime: 3,600 seconds in the example.
- Traffic selectors: HQ LAN and branch LAN, mirrored at the other peer.
FortiOS uses version-specific proposal syntax. Verify the exact available proposal and DH-group options on the installed release. Avoid selecting obsolete algorithms just to make an incompatible configuration connect.
4.3 What is Perfect Forward Secrecy?
Perfect Forward Secrecy (PFS) uses an additional key exchange for the relevant IPsec keying process. When configured correctly, it helps limit the impact of a later compromise of certain long-term keying material on previously established session keys.
Both peers must use compatible PFS settings. If one side requires PFS while the other side has it disabled, Phase 2 negotiation may fail.
5. Firewall Policies and NAT Configuration
Establishing an IPsec tunnel does not automatically permit all traffic between the sites. Firewall policies determine which packets are allowed to enter the tunnel and which traffic can reach the local LAN from the tunnel.
5.1 HQ outbound policy
The infographic shows a policy named HQ_TO_BRANCH. For the example topology, its main settings are:
- Incoming interface: HQ LAN interface.
- Outgoing interface: IPsec tunnel interface.
- Source: 10.10.1.0/24.
- Destination: 10.20.1.0/24.
- Schedule: Always, if approved for the use case.
- Service: Prefer the specific required services rather than ALL in production.
- Action: Accept.
- NAT: Disabled for ordinary private subnet-to-subnet VPN traffic, unless the design requires translation.
5.2 Branch outbound policy
The branch policy should permit the branch LAN to access the intended HQ network through the VPN. Its normal direction is the reverse of the HQ policy:
- Incoming interface: Branch LAN interface.
- Outgoing interface: IPsec tunnel interface.
- Source: 10.20.1.0/24.
- Destination: 10.10.1.0/24.
- Action: Accept for authorized services.
- NAT: Disabled unless a deliberate translation design is required.
Correction to the infographic: The branch firewall policy appears to use the HQ subnet as the source and the branch subnet as the destination. For traffic originating on the branch LAN, the source should normally be 10.20.1.0/24 and the destination 10.10.1.0/24. Verify the actual policy objects and interface names in the deployed configuration.
5.3 Policies for traffic returning from the tunnel
Depending on the FortiOS configuration and tunnel-interface design, the receiving site also needs a policy permitting authorized traffic from the IPsec interface to the local LAN. For example, the HQ side needs a policy that allows approved traffic arriving through the tunnel to reach selected HQ resources. The branch requires the corresponding policy for traffic arriving from HQ.
Policies should be limited to the necessary source networks, destination networks, services, and users or devices. Avoid using broad ALL-to-ALL access unless a clearly justified and controlled requirement exists.
5.4 Why NAT is commonly disabled
For a straightforward routed site-to-site VPN, the source and destination addresses normally remain the original private addresses. Disabling source NAT on the relevant VPN policies preserves those addresses and allows the Phase 2 selectors and routing design to match the intended traffic.
However, NAT may be needed for overlapping subnets or a specific network architecture. Do not disable NAT blindly if the VPN design explicitly requires address translation. Fortinet's documentation explains how NAT processing and Phase 2 selectors interact, so validate the chosen design against the intended traffic flow.
6. Routing Between HQ and Branch
Correct VPN configuration requires both sites to know how to reach the remote private subnet. An established tunnel can remain idle or carry no useful traffic if routing does not direct packets into the IPsec interface.
6.1 Example routes
| Firewall | Destination | Outgoing interface |
|---|---|---|
| HQ | 10.20.1.0/24 | HQ-to-Branch IPsec tunnel |
| Branch | 10.10.1.0/24 | Branch-to-HQ IPsec tunnel |
Depending on the configuration method, FortiGate may create routes as part of the VPN wizard or require routes to be added separately. Verify the actual routing table instead of assuming that creating the tunnel automatically installs every necessary route.
6.2 Check local gateways and return routes
Each endpoint should use the correct local default gateway and subnet mask. The remote site must also have a valid return path. If a server at HQ receives a request from a branch workstation but sends its response through a different gateway, communication may fail even when the tunnel is up.
6.3 Avoid accidental routing loops
Review static routes, dynamic routing, policy routes, and SD-WAN rules when applicable. A route that sends traffic to the wrong interface can bypass the tunnel or send traffic to an unreachable next hop.
7. Example FortiGate CLI Configuration
The following snippets illustrate the configuration structure for an interface-based IPsec tunnel. They are a learning example, not a complete, universal, ready-to-paste production configuration. Exact syntax and available options vary by FortiOS version, interface names, existing objects, and network design.
7.1 HQ: Phase 1 interface example
This example shows the main Phase 1 fields. Replace the peer address and secret with the actual branch values. Confirm the proposal syntax accepted by the installed FortiOS release.
config vpn ipsec phase1-interface
edit "HQ-TO-BRANCH"
set interface "wan1"
set ike-version 2
set remote-gw 198.51.100.10
set proposal aes256-sha256
set dhgrp 14
set keylife 28800
set psksecret "REPLACE_WITH_A_UNIQUE_STRONG_SECRET"
next
end
This snippet is illustrative. It does not include every possible setting for peer identification, DPD, NAT Traversal, local gateway selection, or environment-specific WAN behavior. Configure and validate those settings according to the actual network and FortiOS release.
7.2 HQ: Phase 2 selector example
config vpn ipsec phase2-interface
edit "HQ-TO-BRANCH-P2"
set phase1name "HQ-TO-BRANCH"
set proposal aes256-sha256
set pfs enable
set dhgrp 14
set keylifeseconds 3600
set src-subnet 10.10.1.0 255.255.255.0
set dst-subnet 10.20.1.0 255.255.255.0
next
end
Check the exact Phase 2 parameters available in your firmware. The selectors above represent the HQ local subnet and the remote branch subnet. PFS and the configured DH group must be compatible with the other peer.
7.3 Branch: mirror the Phase 1 peer configuration
At the branch, the remote gateway should point to the HQ public WAN address. The local interface remains the branch's internet-facing interface.
config vpn ipsec phase1-interface
edit "BRANCH-TO-HQ"
set interface "wan1"
set ike-version 2
set remote-gw 203.0.113.1
set proposal aes256-sha256
set dhgrp 14
set keylife 28800
set psksecret "USE_THE_SAME_SECURE_SECRET"
next
end
The pre-shared key must match at both ends. Replace all documentation addresses with real assigned WAN addresses in a real deployment.
7.4 Branch: reverse the Phase 2 selectors
config vpn ipsec phase2-interface
edit "BRANCH-TO-HQ-P2"
set phase1name "BRANCH-TO-HQ"
set proposal aes256-sha256
set pfs enable
set dhgrp 14
set keylifeseconds 3600
set src-subnet 10.20.1.0 255.255.255.0
set dst-subnet 10.10.1.0 255.255.255.0
next
end
The branch's local subnet is 10.20.1.0/24. The HQ subnet is the remote destination, 10.10.1.0/24. This mirrored selector arrangement is essential for a conventional routed site-to-site tunnel.
7.5 Address objects, policies, and routes
In a real configuration, create or verify address objects for the local and remote LANs, add the necessary firewall policies in both directions, and ensure that routes point to the correct IPsec interface. The exact CLI differs according to object naming and whether the tunnel was created by the VPN wizard.
For a typical private subnet-to-subnet design, the intended policy logic is:
- HQ LAN to VPN: source HQ subnet, destination branch subnet, NAT disabled unless the design requires translation.
- VPN to HQ LAN: source branch subnet, destination HQ subnet, permit only authorized services.
- Branch LAN to VPN: source branch subnet, destination HQ subnet, NAT disabled unless required.
- VPN to branch LAN: source HQ subnet, destination branch subnet, permit only authorized services.
Use the FortiGate GUI or the CLI reference for your specific firmware to complete the policy and routing configuration. The official Fortinet administration guide describes site-to-site VPN selectors and routing behavior.
8. Dual ISP, SD-WAN, and High Availability
The infographic shows ISP-1 as the primary link, ISP-2 as a backup, an SD-WAN edge, automatic failover, and link-health monitoring. These are resilience concepts rather than features that become active simply because two ISP labels appear in a diagram.
8.1 Why use two ISPs?
A second ISP can provide an alternate internet path if the primary circuit fails. It may also support different routing policies, service requirements, or traffic distribution. The level of resilience depends on whether the two services share physical infrastructure, upstream providers, power, or other failure points.
8.2 VPN failover design
A robust dual-WAN design may require a separate IPsec tunnel for each WAN path, compatible peer definitions, routes with appropriate preference, health checks, and clear failover criteria. If the primary tunnel becomes unavailable, the secondary route or tunnel can be selected according to the configured design.
Fortinet documents redundant site-to-site IPsec patterns using separate tunnels, route preference, and Dead Peer Detection. A backup ISP does not automatically guarantee VPN continuity; the tunnel and routing behavior must be explicitly designed and tested.
8.3 Dead Peer Detection
Dead Peer Detection (DPD) helps a VPN gateway detect when the remote peer is no longer responding. DPD settings and failure behavior should be configured to match the required recovery time and the behavior of the network path.
8.4 SD-WAN health checks
SD-WAN health checks can monitor the reachability or quality of selected paths. A good design identifies which targets to test, how to interpret loss or latency, and what action should occur when a path becomes unhealthy.
Test the failure scenarios that matter: ISP circuit loss, gateway failure, upstream reachability loss, VPN tunnel failure, and recovery after the primary path returns.
9. Security Best Practices for Site-to-Site VPNs
9.1 Use strong cryptographic settings
Use supported modern algorithms and matching proposals at both peers. The infographic uses AES-256, SHA-256, IKEv2, DH Group 14, and PFS. Validate the combination against current vendor recommendations and organizational security policy rather than assuming every combination is optimal for every deployment.
9.2 Restrict firewall policies
Permit only the required subnets and services. For example, a branch workstation may need access to a specific application server at HQ but should not automatically receive access to every server, firewall management interface, or backup system.
9.3 Protect management access
Restrict firewall administration to trusted management networks or approved remote-access paths. Use individual administrator accounts, multi-factor authentication where supported, secure management protocols, and role-based permissions.
9.4 Use unique secrets or certificates
Do not reuse a demonstration pre-shared key. Use strong unique secrets, store them securely, and rotate them under a documented process. Consider certificate-based authentication when it better fits the organization's scale and security requirements.
9.5 Enable logging and monitoring
Collect relevant VPN events, firewall policy logs, system events, and traffic information. Monitor tunnel state, negotiation errors, unusual traffic, and repeated authentication failures. Send logs to an approved central logging or SIEM platform when available.
9.6 Review endpoint and network security
The VPN connects networks, not just trusted devices. Use endpoint protection, patching, access control, network segmentation, and least-privilege rules to limit the consequences of a compromised workstation or server.
9.7 Keep configuration backups
Maintain encrypted backups of known-good firewall configurations and document change history. Limit access to backups because they may contain sensitive network details and security configuration data.
10. Network Services and Enterprise Integration
The infographic shows identity services, wireless access, network endpoints, data infrastructure, security protection, and monitoring operations. These systems may be connected across the site-to-site VPN, but access should be deliberately scoped.
10.1 Identity and directory services
Active Directory, DNS, DHCP, RADIUS, TACACS+, and certificate services may support authentication and network operations. Avoid making every branch device able to access every identity server port. Define the required services and source networks.
10.2 Wireless and guest access
Corporate Wi-Fi, guest Wi-Fi, and device networks should use appropriate segmentation and access policies. Guest users typically should not be able to reach private corporate resources merely because the wireless network is connected to a site with a VPN.
10.3 Servers, backup, and replication
File servers, backup systems, databases, virtualization platforms, and replication services may communicate between sites. Backup and replication traffic can consume significant bandwidth, so capacity planning, schedules, access restrictions, and encryption requirements should be considered.
10.4 Security operations
IDS/IPS, next-generation firewalls, web application firewalls, anti-malware, DNS security, and SIEM platforms can complement VPN security. These controls address different risks; the VPN should not be treated as a replacement for application security or monitoring.
10.5 Cloud integration
Organizations may use VPN connectivity alongside Microsoft 365, Azure, AWS, or other cloud services. Cloud routing, identity, access policies, and security controls must be planned separately. A site-to-site tunnel to one network does not automatically secure every cloud service or application.
11. Troubleshooting IPsec VPN Connectivity
When a tunnel does not work, isolate the problem systematically. Determine whether Phase 1 is established, whether Phase 2 is established, whether routes are correct, and whether firewall policies permit the desired traffic.
| Problem | Likely causes | What to check |
|---|---|---|
| Phase 1 down | Peer address, WAN route, blocked IKE, authentication or proposal mismatch. | WAN reachability, UDP 500/4500, IKE logs, key, IKE version, proposal, DH group. |
| Phase 1 up, Phase 2 down | Selectors, PFS group, encryption/integrity proposal or lifetime mismatch. | Compare local/remote selectors and Phase 2 settings at both ends. |
| Tunnel up, no traffic | Missing route, wrong selectors, firewall policy, endpoint gateway, or NAT issue. | Routing table, policy hits, packet counters, host gateway, return route. |
| One-way traffic | Missing reverse policy, asymmetric route, host firewall, or incorrect selector. | Check both directions and confirm the return path. |
| VPN fails after ISP change | Wrong peer address, missing backup tunnel, stale route, or failover design issue. | WAN status, peer reachability, tunnel status, SD-WAN rules and route preference. |
| VPN disconnects intermittently | Unstable WAN, upstream NAT timeout, DPD behavior, rekey issue, or packet loss. | Event logs, WAN health, rekey events, DPD logs, upstream device behavior. |
11.1 Step-by-step troubleshooting process
- Verify the WAN interfaces: Confirm that both firewalls have working internet connectivity and the correct interface addresses.
- Verify peer addresses: Each firewall must point to the correct remote VPN gateway.
- Check Phase 1: Compare IKE version, authentication, proposals, DH group, and pre-shared key or certificates.
- Check Phase 2: Compare encryption, integrity, PFS, DH group, lifetime, and traffic selectors.
- Check routes: Verify that the remote LAN subnet is routed through the intended tunnel.
- Check firewall policies: Confirm that the correct LAN-to-VPN and VPN-to-LAN policies exist and are being matched.
- Check NAT: Ensure that address translation matches the design and is not unexpectedly changing the source address.
- Test both directions: Use an authorized test host at each site and confirm the return path.
- Review logs and counters: Use the IPsec monitor and relevant logs to identify negotiation or traffic failures.
- Document the resolution: Record the fault, root cause, configuration changes, and successful test results.
11.2 Useful FortiGate diagnostic commands
These commands are common diagnostic examples, but output and options may vary by FortiOS version. Run them with appropriate administrative privileges and avoid leaving verbose debugging enabled after troubleshooting.
get vpn ipsec tunnel summary diagnose vpn ike gateway list diagnose vpn tunnel list get router info routing-table all
To investigate IKE negotiation problems, FortiGate also provides IKE debug commands. Use the official documentation for the installed release, filter the output to the relevant tunnel where possible, and stop debugging when the required evidence has been collected.
12. Monitoring, Logging, and Operations
A site-to-site VPN should be monitored after deployment, not merely tested once. The infographic includes Microsoft Sentinel, SOC monitoring, NetFlow analysis, a syslog server, and real-time dashboards.
12.1 Monitor tunnel availability
Track whether the IKE and IPsec SAs are established, how long the tunnel has been available, and whether rekeying or negotiation failures are recurring. A tunnel may appear configured but still fail to carry traffic due to routing or policy errors.
12.2 Centralize logs
Forward appropriate firewall and VPN events to an approved log platform. Include enough information to investigate outages and security events while protecting sensitive data and restricting access to logs.
12.3 Monitor traffic and performance
Observe bandwidth utilization, latency, packet loss, errors, and unusual traffic patterns. A tunnel can be technically up but still perform poorly because of a saturated ISP circuit, MTU issues, congestion, or excessive retransmissions.
12.4 Test alerts and recovery
Verify that alerts reach the responsible operations team. Conduct controlled tests for tunnel failure, WAN loss, and restoration during an approved maintenance window. Record recovery times and confirm that failover behavior meets the organization's requirements.
13. Enterprise Benefits of Site-to-Site IPsec VPN
13.1 Secure site-to-site connectivity
IPsec protects supported traffic between sites across untrusted networks. Correct peer authentication, encryption, selectors, and firewall rules help limit exposure while allowing approved communication.
13.2 Cost-effective connectivity
Using an encrypted tunnel over internet connectivity can be a cost-effective option compared with some dedicated private connectivity services. The right choice depends on bandwidth, availability, latency, service-level requirements, and operational costs.
13.3 Scalability
Organizations can add new sites, subnets, or tunnels as requirements grow. Good naming, consistent configuration templates, address planning, and centralized monitoring reduce the complexity of larger deployments.
13.4 High availability and redundancy
Dual ISPs, redundant VPN tunnels, suitable routing, and health checks can improve resilience. Redundancy must be engineered and tested; two circuits do not guarantee continuity if both depend on the same upstream infrastructure.
13.5 Hybrid cloud integration
Site-to-site VPNs can connect on-premises networks with compatible cloud network gateways. Cloud routes, access policies, identity controls, and application requirements still need separate planning.
13.6 Centralized management
Standardized configurations, centralized logging, and documented change procedures make it easier to manage and troubleshoot connections across multiple sites.
13.7 Zero Trust alignment
A VPN can provide protected transport, but it should not grant unrestricted trust to every device at the other end. Least-privilege access, identity verification, endpoint security, and segmentation remain important.
13.8 Business continuity
Reliable inter-site connectivity can support selected backup, replication, application, and recovery workflows. Test the complete recovery process, including authentication dependencies, DNS, routing, and application access.
14. VPN Deployment Success Checklist
- ☐ The HQ and branch WAN interfaces have working internet connectivity.
- ☐ The remote gateway address is correct at each site.
- ☐ IKEv2 and the Phase 1 proposals match.
- ☐ Authentication credentials or certificates are correct.
- ☐ Phase 2 encryption and integrity proposals match.
- ☐ PFS and DH-group settings are compatible.
- ☐ HQ selectors use local 10.10.1.0/24 and remote 10.20.1.0/24.
- ☐ Branch selectors use local 10.20.1.0/24 and remote 10.10.1.0/24.
- ☐ Required routes exist at both sites.
- ☐ Firewall policies permit only the required traffic in both directions.
- ☐ NAT settings match the intended VPN design.
- ☐ Authorized hosts can communicate across the tunnel.
- ☐ Return traffic follows the correct route.
- ☐ Tunnel and security logs are available for monitoring.
- ☐ The configuration is backed up and documented.
- ☐ Dual-ISP failover has been tested if it is part of the design.
15. Frequently Asked Questions
What is a site-to-site IPsec VPN?
It is an encrypted network connection between two gateways that allows authorized traffic to travel between their private networks over an untrusted network such as the internet.
What is the difference between Phase 1 and Phase 2?
Phase 1 establishes the IKE Security Association used for secure negotiation and peer authentication. Phase 2 establishes the IPsec protection for selected data traffic between the networks.
Why must Phase 2 selectors be mirrored?
The local and remote subnets at one peer correspond to the remote and local subnets at the other peer. If the selectors do not describe compatible traffic in opposite directions, the Phase 2 negotiation or data forwarding may fail.
Why is NAT commonly disabled for site-to-site VPN policies?
For a typical routed private-network VPN, source and destination addresses should remain unchanged so that routes and traffic selectors match. NAT may still be required for special designs such as overlapping subnets.
Can a VPN be up but still not pass traffic?
Yes. Routes, firewall policies, selectors, NAT behavior, host gateways, endpoint firewalls, and return paths can prevent traffic even when the tunnel is established.
What is the role of DPD?
Dead Peer Detection helps a gateway identify an unresponsive VPN peer. It can support recovery and failover behavior when combined with appropriate routes and tunnel configuration.
Does having two ISPs automatically provide VPN failover?
No. The VPN tunnels, peer addresses, routes, health checks, and failover logic must be configured and tested. Actual resilience also depends on the independence of the ISP paths.
Is AES-256 alone enough to secure a VPN?
No. Security also depends on peer authentication, compatible integrity and key-exchange settings, secure secrets, correct firewall policies, software maintenance, and monitoring.
16. Conclusion
A properly configured IPsec site-to-site VPN gives organizations a secure way to connect headquarters and branch networks over public internet links. Reliable deployment requires more than selecting AES-256 and enabling a tunnel: both gateways must agree on IKE and IPsec parameters, use compatible traffic selectors, have correct routes, and permit the intended traffic through firewall policies.
The example in this guide uses IKEv2, AES-256, SHA-256, DH Group 14, PFS, and a 3,600-second Phase 2 lifetime. The most important configuration checks are the remote peer addresses, matching Phase 1 proposals, mirrored Phase 2 selectors, reverse-direction firewall policies, and appropriate NAT behavior.
For enterprise deployments, combine the VPN with least-privilege firewall rules, strong authentication, protected management access, centralized logging, configuration backups, and tested dual-ISP failover where required. Validate all settings against the installed FortiOS version and the organization's security requirements before putting the tunnel into production.
Learn More with LearnCyber.in
Explore practical guides on networking, cybersecurity, firewalls, VPNs, enterprise infrastructure, and network troubleshooting.
Official Documentation and Further Reading
- Fortinet: Site-to-site VPN configuration and traffic selectors
- Fortinet: Phase 1 configuration
- Fortinet: IPsec monitor
- Fortinet: Redundant site-to-site IPsec VPN design
Disclaimer: This article is an educational configuration guide. FortiOS commands, menu locations, and available cryptographic options may differ by release and device model. Verify the configuration against the documentation for your installed version and test changes in a lab or approved maintenance window before production deployment.
