FortiGate IPsec VPN Explained: Phase 1 and Phase 2 Configuration

September 07, 2026

FortiGate IPsec VPNs are widely used to create secure communication between branch offices, data centers, cloud environments, and remote networks. They protect sensitive traffic by encrypting data as it travels across public networks such as the internet, making them an important part of modern enterprise security.

Professionals taking Fortinet NSE4 Training should understand how IPsec VPNs work because VPN configuration, routing, firewall policies, encryption, and troubleshooting are core FortiGate administration skills. A FortiGate IPsec VPN mainly depends on two negotiation stages, Phase 1 and Phase 2, which work together to establish trust and securely carry network traffic.

What Is a FortiGate IPsec VPN?

IPsec stands for Internet Protocol Security. It is a collection of protocols designed to protect IP traffic through encryption, authentication, and integrity checking.

A FortiGate IPsec VPN creates an encrypted tunnel between two VPN gateways over an untrusted network such as the internet. This allows organizations to connect different locations securely without requiring a dedicated private WAN connection.

For example, a company may have one FortiGate firewall at its headquarters and another at a branch office. An IPsec tunnel can securely carry traffic between the internal networks of both locations.

Before user traffic can pass through the tunnel, the two VPN peers must negotiate security parameters. This process mainly takes place through Phase 1 and Phase 2.

How Does FortiGate IPsec VPN Work?

The IPsec negotiation process can be divided into two stages.

Phase 1

Phase 1 creates a secure and authenticated communication channel between the two VPN gateways.

The devices authenticate each other and negotiate parameters such as encryption algorithms, authentication methods, IKE versions, and Diffie-Hellman groups.

Phase 2

Phase 2 creates the Security Associations used to protect actual network traffic.

It also defines which local and remote networks should communicate through the VPN.

Both phases must complete successfully for normal encrypted communication to take place.

FortiGate IPsec VPN Phase 1 Explained

Phase 1 is responsible for establishing trust between the VPN peers.

FortiGate uses Internet Key Exchange, or IKE, to negotiate the Phase 1 connection. The devices compare their configurations and attempt to agree on compatible security parameters.

If important settings do not match, Phase 1 may fail and the VPN tunnel will not establish.

Important Phase 1 Parameters

Remote Gateway

The remote gateway identifies the VPN device on the opposite side of the tunnel.

In a common site-to-site VPN deployment, this is the public IP address of the remote firewall.

FortiGate can also support VPN peers using dynamic IP addresses depending on the deployment type.

Authentication Method

VPN peers must verify each other's identity.

A commonly used method is a pre-shared key. The same key must be configured correctly on both VPN peers.

Certificate-based authentication may also be used in environments that require stronger identity verification or centralized certificate management.

IKE Version

FortiGate supports both IKEv1 and IKEv2.

IKEv2 is commonly preferred in modern deployments because of its improved efficiency and negotiation process.

IKEv1 may still be used when connecting to older VPN devices or existing environments that depend on it.

Encryption Algorithm

Encryption protects VPN negotiation data from unauthorized access.

AES-based encryption algorithms are commonly used. Both VPN peers must support compatible encryption settings for Phase 1 to succeed.

Diffie-Hellman Group

Diffie-Hellman allows the VPN peers to securely establish shared keying material over an untrusted connection.

Both sides must negotiate compatible Diffie-Hellman parameters.

Phase 1 Lifetime

The Phase 1 lifetime determines how long the IKE Security Association remains active before renegotiation takes place.

Administrators should verify compatible values when configuring VPN devices from different vendors.

FortiGate Phase 1 Configuration Example

A simple route-based Phase 1 configuration may look like this:

config vpn ipsec phase1-interface

edit "Branch-VPN"

set interface "wan1"

set ike-version 2

set remote-gw 203.0.113.10

set psksecret your-pre-shared-key

end

The config vpn ipsec phase1-interface command is used to configure the Phase 1 interface for a route-based VPN.

The tunnel interface can later be referenced by firewall policies and routing configuration.

FortiGate IPsec VPN Phase 2 Explained

After Phase 1 establishes the secure negotiation channel, Phase 2 creates the IPsec Security Associations used to encrypt actual user traffic.

Phase 2 determines which traffic should be protected by the VPN.

For example, consider the following networks:

Headquarters:

192.168.10.0/24

Branch office:

192.168.20.0/24

These networks can be configured as Phase 2 selectors so that traffic between them is protected by the IPsec tunnel.

Important Phase 2 Parameters

Local Network

The local network defines the subnet located behind the local FortiGate.

For example:

192.168.10.0/24

Remote Network

The remote network defines the subnet located behind the remote VPN gateway.

For example:

192.168.20.0/24

The opposite FortiGate usually has these networks configured in reverse.

Encryption and Authentication

Phase 2 also negotiates the cryptographic settings used to protect data passing through the tunnel.

The configurations on both VPN peers must be compatible.

Perfect Forward Secrecy

Perfect Forward Secrecy, or PFS, can provide additional security during Phase 2 key generation.

When PFS is enabled, fresh keying material is generated through another Diffie-Hellman exchange.

Both peers must use compatible PFS settings.

Phase 2 Lifetime

The Phase 2 lifetime determines how long the IPsec Security Association remains active before new keys are negotiated.

Periodic rekeying helps reduce the amount of traffic protected using the same cryptographic keys.

FortiGate Phase 2 Configuration Example

A simple Phase 2 configuration may look like this:

config vpn ipsec phase2-interface

edit "Branch-VPN-P2"

set phase1name "Branch-VPN"

set src-subnet 192.168.10.0 255.255.255.0

set dst-subnet 192.168.20.0 255.255.255.0

end

The phase1name parameter links Phase 2 with the appropriate Phase 1 tunnel.

The source and destination subnets define the protected traffic.

Phase 1 vs Phase 2 in FortiGate

Phase 1 and Phase 2 perform different functions even though they are part of the same VPN negotiation.

Phase 1 Creates Trust

Phase 1 handles:

VPN peer authentication
IKE negotiation
Encryption parameters
Diffie-Hellman exchange
Secure control channel creation

Phase 2 Protects Data

Phase 2 handles:

Local and remote traffic selectors
Data encryption
PFS settings
IPsec Security Associations
Phase 2 rekeying

A simple way to remember the difference is that Phase 1 secures communication between the VPN gateways, while Phase 2 secures the traffic travelling through the tunnel.

Routing Requirements for FortiGate IPsec VPN

A working IPsec tunnel also requires correct routing.

In a route-based deployment, the FortiGate must know that the remote network is reachable through the VPN interface.

For example, the headquarters FortiGate may require a route for:

192.168.20.0/24

pointing toward the Branch-VPN interface.

Static routing is commonly used in smaller environments, while dynamic routing protocols may be used in larger networks.

Firewall Policies for IPsec VPN Traffic

Firewall policies determine whether traffic is allowed to enter or leave the IPsec tunnel.

A typical site-to-site VPN may require one policy from the internal LAN toward the VPN interface and another policy from the VPN interface toward the LAN.

Administrators should verify source addresses, destination addresses, services, interfaces, and NAT settings.

For normal private network-to-private network VPN traffic, NAT is generally disabled unless the network design specifically requires translation.

Common FortiGate IPsec VPN Problems

Pre-Shared Key Mismatch

Different pre-shared keys on the two devices can prevent Phase 1 authentication.

Proposal Mismatch

Different encryption, authentication, or Diffie-Hellman settings can cause negotiation failure.

Incorrect Phase 2 Selectors

Incorrect local or remote networks may prevent Phase 2 from establishing correctly.

Missing Routes

The tunnel may be established, but traffic can still fail when the FortiGate does not have a route to the remote network.

Missing Firewall Policies

Traffic may also be blocked if the required firewall policies are not configured.

FortiGate IPsec VPN Troubleshooting Commands

FortiGate provides useful CLI commands for checking VPN status.

get vpn ipsec tunnel summary

This command provides a quick summary of IPsec tunnels.

Another useful command is:

diagnose vpn tunnel list

It displays more detailed information about tunnels and IPsec Security Associations.

Administrators can also use IKE debug commands when troubleshooting deeper Phase 1 or Phase 2 negotiation problems.

Best Practices for FortiGate IPsec VPN

Use secure and modern encryption algorithms supported by both VPN peers.

Keep Phase 1 and Phase 2 settings consistent between devices.

Document local and remote subnets before starting the configuration.

Verify routing and firewall policies after creating the tunnel.

Use clear VPN tunnel names to simplify troubleshooting.

Review tunnel status regularly and investigate repeated negotiation or rekeying failures.

Conclusion

FortiGate IPsec VPN configuration becomes easier to understand when Phase 1 and Phase 2 are treated as two separate stages. Phase 1 authenticates the VPN gateways and creates a secure negotiation channel, while Phase 2 creates the Security Associations required to encrypt actual network traffic between defined networks.

Learning IPsec together with routing, firewall policies, authentication, NAT, and troubleshooting provides a stronger foundation for managing FortiGate environments. A practical Fortinet NSE4 course can help learners build these skills through hands-on configurations and real-world troubleshooting scenarios that reflect how VPNs are deployed in enterprise networks.