Site-to-Site IPsec VPNs. They solve the fundamental problem of connecting two separate physical networks, like a head office and a branch, securely over the public internet. For the NSE4 exam, mastering this concept is critical as it represents the core of how Fortinet devices create secure, encrypted links between locations, replacing expensive private leased lines.
Jump to a section
A simple way to picture Site-to-Site IPsec VPNs
A shipping manager for a large warehouse in Manchester. This manager is responsible for securely sending a shipment of valuable electronics to a partner warehouse in Berlin, ensuring nothing is intercepted, tampered with, or lost along the way.
The manager doesn't just throw the boxes onto a random truck. First, they call their counterpart in Berlin to agree on the security details. They must both decide on the secret handshake (a pre-shared key), the type of security seal for each box (encryption algorithm), and how often to change the seal combination (key lifetime). This initial negotiation is like IKE Phase 1, establishing a secure control channel between the two warehouses.
Once the security guard channel is established over the phone, they move to the specifics of the shipment. They decide the boxes will be shipped via a specific courier (IPsec protocol like ESP), the exact route the truck will take (the tunnel), and that each box's address label will be encrypted (encapsulation). This detailed planning is like IKE Phase 2, setting up the data tunnel.
Finally, the trucks (encrypted packets) start rolling back and forth between the two warehouses. The shipping manager's job is done only when data can flow securely through this dedicated, secure corridor, exactly as a site-to-site IPsec VPN connects two office networks over the public internet.
Let's break down what a Site-to-Site IPsec VPN actually is, starting from the very beginning.
Imagine you have two offices: one in London and one in Paris. They are miles apart. You want them to function like one big office network so that a computer in London can talk to a printer in Paris as if they were in the same room. The problem is that the internet between them is a public space, like a busy street where anyone could listen in or intercept your data. You wouldn't send a secret letter on a postcard where anyone can read it, would you? You need a secure, sealed envelope. A Site-to-Site IPsec VPN is that sealed envelope for your network traffic.
What is a VPN? VPN stands for Virtual Private Network. 'Virtual' means it's not a physical cable. 'Private' means it's secured and exclusive. 'Network' means it connects two or more networks. So, it's a secure, encrypted connection between two locations over a public network (the internet).
What does 'Site-to-Site' mean? This is crucial. Unlike a 'Remote Access' VPN where a single user (like an employee working from a coffee shop) connects to an office network, a Site-to-Site VPN connects *entire networks*. Think two routers talking to each other. The users in London don't need to manually connect; the VPN is always on between the two office firewalls or routers. The London network and the Paris network become one logical network.
What is IPsec? IPsec stands for Internet Protocol Security. It is a suite of protocols (a set of rules) that provides security for IP communications. It works by authenticating and encrypting each IP packet of a data stream. IPsec operates at Layer 3 (the Network Layer) of the OSI model, meaning it can secure any application that uses IP, from web browsing to file sharing.
The Two-Phase Process (IKE) IPsec uses a protocol called IKE (Internet Key Exchange) to set up the secure connection. IKE has two phases, which is a core exam concept.
Phase 1: The Control Channel (The Secure Tunnel for Negotiating) This phase establishes a secure, authenticated channel between the two VPN endpoints (the two FortiGates). Think of it as the administrators from both offices having a secure, encrypted phone call to agree on how to build the main tunnel. During Phase 1, they negotiate: - Encryption Algorithm: The method for scrambling the data (e.g., AES-128, AES-256). - Authentication Algorithm: The method for verifying the data hasn't changed (e.g., SHA-1, SHA-256). - Diffie-Hellman Group: A method for securely exchanging secret keys over a public medium. - Pre-Shared Key (PSK): A secret password both sides must know. Think of it as the 'secret handshake'. - Lifetime: How long this Phase 1 tunnel will last before it needs to be renegotiated (e.g., 86400 seconds, or 24 hours).
The result of Phase 1 is an ISAKMP (Internet Security Association and Key Management Protocol) tunnel, sometimes called the 'management' or 'control' tunnel.
Phase 2: The Data Tunnel (The Actual Secure Path) Once the secure control channel from Phase 1 is established, Phase 2 negotiates the specific parameters for the actual data traffic. This is where the real work gets done. During Phase 2, they negotiate: - IPsec Protocol: Usually ESP (Encapsulating Security Payload), which provides both encryption and authentication. AH (Authentication Header) is another option but is rarely used. - Encryption and Authentication Algorithms: These can be different from Phase 1. They are applied to the actual user data packets. - Traffic Selectors: This defines *which* traffic should be sent through the VPN. For example, 'all traffic from the 192.168.1.0/24 subnet (London) to the 10.0.0.0/24 subnet (Paris)'. - Lifetime: The duration of the Phase 2 security associations (SAs), often shorter than Phase 1 (e.g., 3600 seconds, or 1 hour).
The result of Phase 2 is two unidirectional IPsec Security Associations (SAs) – one for incoming traffic, one for outgoing traffic. These SAs are the keys used to encrypt and decrypt the actual data flowing through the VPN tunnel.
Tunnel Interfaces In FortiGate, you configure a 'Tunnel Interface' (a virtual network interface like 'tunnel.1'). This interface is the endpoint of the VPN tunnel. You add a route pointing to the remote network (e.g., Paris network) through this tunnel interface. When traffic from the London network matches that route, the FortiGate encapsulates it, encrypts it, and sends it out through the tunnel interface to the Paris FortiGate. The receiver decrypts it and forwards the original packet to the internal Paris network.
Why use a Site-to-Site IPsec VPN? It replaces expensive, dedicated private WAN links (like MPLS). It offers secure connectivity using the cheap public internet, provides encryption for sensitive data, and allows for flexible, scalable network design.
Define the Network Topology
Identify the public IP addresses and internal subnets of both sites. For example, Site A has public IP 1.1.1.1 and internal subnet 192.168.1.0/24. Site B has public IP 2.2.2.2 and internal subnet 10.0.0.0/24. This mapping defines the tunnel's endpoints.
Configure Phase 1 on Site A
On the FortiGate, create a new IPsec tunnel. Set the remote gateway to Site B's public IP (2.2.2.2). Choose the WAN interface. Set the authentication method to Pre-shared Key and enter a secret password. Select IKE version (usually v2). Choose encryption (e.g., AES256) and authentication (e.g., SHA256). Set the DH group (e.g., Group 14). This establishes the secure negotiation channel.
Configure Phase 2 on Site A
In the same tunnel configuration, define the Phase 2 selectors. Set the local address to Site A's local subnet (192.168.1.0/24) and the remote address to Site B's remote subnet (10.0.0.0/24). Choose ESP as the protocol. Set encryption and authentication algorithms. Set the Phase 2 lifetime. This defines the parameters for the actual data encryption.
Add a Static Route on Site A
Navigate to the static routes section. Add a new route: destination is the remote subnet (10.0.0.0/24), interface is the newly created tunnel interface (e.g., 'to_site_b'), gateway is left as 0.0.0.0. This tells the FortiGate to send any traffic destined for 10.0.0.0/24 through the VPN tunnel.
Create Firewall Policies on Site A
Create two policies. First, inbound policy from 'internal_interface' to 'to_site_b' tunnel interface, allowing traffic from 192.168.1.0/24 to 10.0.0.0/24. Second, outbound policy from 'to_site_b' to 'internal_interface', allowing traffic from 10.0.0.0/24 to 192.168.1.0/24. Without these, traffic is blocked by the firewall.
Repeat Steps 2-5 on Site B
On Site B's FortiGate, mirror the configuration exactly, but with settings reversed. The local subnet becomes 10.0.0.0/24, the remote subnet becomes 192.168.1.0/24, and the remote gateway is Site A's public IP (1.1.1.1). The pre-shared key must be identical. Add the static route and firewall policies on this side as well.
Verify the VPN Tunnel
Use the FortiGate GUI monitor (VPN > Monitor > IPsec Monitor) or CLI commands like 'diagnose vpn ike gateway list' to check the tunnel status. Both Phase 1 and Phase 2 should show as 'up'. Then perform a ping test from a device on Site A's subnet to a device on Site B's subnet to confirm traffic flows.
Let's imagine you are a junior IT administrator at 'GreenLeaf Stores', a company with three locations: a Head Office in London, a Warehouse in Birmingham, and a new Retail Shop in Manchester. The company uses a central inventory database at Head Office. The Warehouse and the Shop both need to access this database. Your task is to set up Site-to-Site IPsec VPNs using a FortiGate firewall.
Here is what you would actually do, step by step:
Step 1: The Plan and the Requirements You sit with your senior colleague. You need to determine:
The public IP addresses of each FortiGate. For example, Head Office has static IP 100.100.100.1, Warehouse has 200.200.200.1, Shop has 300.300.300.1.
The internal subnet at each site: Head Office uses 192.168.1.0/24, Warehouse uses 10.10.10.0/24, Shop uses 172.16.0.0/24.
You decide which sites talk to which: Warehouse and Shop both need to connect to Head Office, but they don't need to talk to each other. So you will configure two separate Site-to-Site VPNs: one between Head Office and Warehouse, and another between Head Office and Shop.
Step 2: Configuring the FortiGate at Head Office (London) You log into the FortiGate web interface. For each VPN, you navigate to the 'VPN > IPsec Tunnels' menu. - Phase 1 Proposal: You create a new Phase 1. You give it a name, like 'To_Birmingham'. You enter the remote gateway IP (200.200.200.1). You choose the interface (the WAN port connected to the internet). You set authentication method to 'Pre-shared Key' and type in the secret password 'GreenLeafSecret'. You choose IKE version (typically v2). You select an encryption algorithm (e.g., AES256) and an authentication algorithm (e.g., SHA256). You set the Diffie-Hellman group (e.g., Group 14). This establishes the secured control channel. - Phase 2 Proposal: Still within the same tunnel configuration, you go to the Phase 2 selectors. You define the 'Local Address' as the Head Office subnet (192.168.1.0/24) and the 'Remote Address' as the Warehouse subnet (10.10.10.0/24). You choose ESP as the protocol, and confirm encryption/authentication algorithms (which can be the same as Phase 1 or different). You set the Phase 2 lifetime to 3600 seconds. - Tunnel Interface & Routing: FortiGate automatically creates a 'tunnel' interface (e.g., 'To_Birmingham'). You then go to 'Network > Routing > Static Routes'. You add a static route: destination is 10.10.10.0/24, interface is 'To_Birmingham', gateway is 0.0.0.0 (since it's a point-to-point tunnel). Without this route, the FortiGate would not know to send traffic for the Warehouse network into the VPN tunnel. - Policies: Finally, you create firewall policies. You create a policy from the internal LAN interface to the 'To_Birmingham' tunnel interface, and another from the tunnel interface to the LAN. These policies allow the traffic to flow. Without them, the VPN tunnel might be up, but traffic would be blocked by the firewall.
Step 3: Configuring the Warehouse FortiGate (Birmingham) You log into the Warehouse's FortiGate. You repeat the process, but this time the Local Address is the Warehouse subnet (10.10.10.0/24) and the Remote Address is the Head Office subnet (192.168.1.0/24). The Remote Gateway IP will be the Head Office public IP (100.100.100.1). The Pre-Shared Key must be identical: 'GreenLeafSecret'. You also need to add the static route on this side: destination 192.168.1.0/24 via the tunnel interface. You create the corresponding firewall policies.
Step 4: Verification You go back to the Head Office FortiGate. You navigate to 'Monitor > IPsec Monitor'. You can see your tunnel 'To_Birmingham' is listed and the status is 'UP'. This means the IKE negotiations succeeded. You can also run diagnostic commands or a ping test. You ask a user in Birmingham to ping a server at Head Office (192.168.1.10). If it works, the VPN is functional. You repeat the entire process for the Manchester shop. Congratulations, you have just successfully interconnected three separate networks into a private, secure WAN.
The NSE4 exam is not just about theory; it tests your ability to apply configuration knowledge. For Exam Objective 5.1, 'Configure site-to-site IPsec VPNs including IKE versions, phase 1 and phase 2 settings, and tunnel interfaces', the questions are designed to be precise and tricky. Here is what you need to know:
What the Exam Tests: - Phase 1 vs Phase 2: The number one thing the exam tests is your ability to differentiate between Phase 1 settings (which create the control channel) and Phase 2 settings (which create the data channel). They will show you a list of parameters and ask 'Which of these is configured in Phase 1/Phase 2?' - IKE Versions: They love to test the differences between IKEv1 and IKEv2. IKEv2 has fewer exchanges, is more efficient, and has built-in NAT traversal and dead peer detection. IKEv1 uses main mode or aggressive mode for Phase 1. Remember, IKEv2 is the modern standard. - Traffic Selectors: A common trap question. The exam will give you two subnets and ask which 'allows all traffic' between them. The correct answer for the traffic selector is typically '0.0.0.0/0.0.0.0' for local and remote, but the exam loves the specific subnet-to-subnet selectors. Know how to define them. - Dead Peer Detection (DPD): You will be asked what happens when a remote VPN peer goes offline. DPD is how the FortiGate detects the peer is down so it can bring down the tunnel and attempt to re-establish it. - Route Injection: This is a FortiGate-specific feature. The exam will test that you can inject a route from a tunnel interface into the routing table automatically (e.g., via OSPF or RIP, or via the 'Add Route' checkbox in the Phase 2 configuration). - NAT Traversal (NAT-T): If both VPN peers are behind a NAT device (a router doing NAT), exam questions will ask what needs to be enabled. The answer is NAT Traversal, which adds a UDP header to the IPsec packet to allow it to pass through NAT successfully.
Common Exam Traps: - Matching Parameters: They will present a scenario where Phase 1 encryption on one side is AES256, and on the other side it's 3DES. The tunnel will fail. The trap is that the parameters (encryption, authentication, DH group) must match on both ends for the negotiation to succeed. - Pre-Shared Key Mismatch: An obvious one, but the exam will disguise it. The PSK must be identical on both peers. If you see an answer option that says 'Change the PSK on one side to match', it is often the correct path. - Interface vs. Policy: The exam will ask about the relationship between the tunnel interface, the static route, and the firewall policy. One question might present a scenario where the tunnel is up but no traffic flows. The answer is likely a missing firewall policy or an incorrect static route. - Main Mode vs. Aggressive Mode (IKEv1): Main mode is more secure (it hides the identities of the peers) but is slower. Aggressive mode is faster but sends the identity in clear text. Know that IKEv2 is preferred.
Key Definitions to Memorise: - ISAKMP Tunnel: The Phase 1 tunnel. - IPsec SA (Security Association): The Phase 2 tunnel (two unidirectional SAs). - Proxy-ID: Another name for the traffic selector in some vendors, including Fortinet. - AH vs ESP: AH provides only authentication (integrity), ESP provides both encryption and authentication. ESP is the standard. - Tunnel vs Transport Mode: Site-to-Site uses 'Tunnel Mode', which encrypts the entire original IP packet. 'Transport Mode' only encrypts the payload and is used for end-to-end connections.
Focus on understanding the logic of the conversation between two FortiGates. If you can think like the protocol, you can answer the exam questions accurately.
A Site-to-Site IPsec VPN connects two entire networks securely over the public internet by encrypting all traffic between them.
IPsec uses a two-phase process called IKE: Phase 1 sets up a secure control channel, and Phase 2 negotiates the specific parameters for the data tunnel.
Phase 1 parameters (encryption, authentication, DH group, PSK) must be identical on both VPN peers or the tunnel will fail to establish.
The traffic selector (or Proxy-ID) in Phase 2 defines exactly which subnets are allowed to communicate over the VPN tunnel.
A FortiGate VPN tunnel requires three things to function: the IPsec configuration, a static route pointing traffic into the tunnel interface, and a corresponding firewall policy to permit the traffic.
IKEv2 is the preferred version due to improved efficiency, built-in NAT traversal, and better stability compared to IKEv1.
These come up on the exam all the time. Here's how to tell them apart.
IKE Phase 1
Establishes a secure control channel for negotiation.
Uses a single ISAKMP SA.
Negotiates DH group, encryption, and authentication for the key exchange.
IKE Phase 2
Establishes the actual data tunnel for user traffic.
Creates two unidirectional IPsec SAs (one inbound, one outbound).
Negotiates traffic selectors (Proxy-IDs) and the specific encryption for data packets.
IPsec Tunnel Mode
Encrypts the entire original IP packet.
Commonly used for Site-to-Site VPNs.
Adds a new IP header to the encrypted packet.
IPsec Transport Mode
Only encrypts the payload of the IP packet.
Commonly used for end-to-end host-to-host connections.
Does not add a new IP header; the original header remains readable.
ESP (Encapsulating Security Payload)
Provides both encryption and authentication.
Is the standard protocol used in modern IPsec VPNs.
Supports NAT traversal (with a UDP wrapper).
AH (Authentication Header)
Provides only authentication and integrity checking, no encryption.
Is rarely used because it does not protect data confidentiality.
Cannot be used through NAT because it authenticates the IP header, which NAT must change.
IKEv1 Main Mode
Exchanges six messages in three round trips.
Provides identity protection (hides peer IP addresses).
Is more secure but slower to establish.
IKEv1 Aggressive Mode
Exchanges three messages in one round trip.
Sends peer identities in clear text during negotiation.
Is faster but less secure; vulnerable to man-in-the-middle attacks.
Static Route for VPN
Tells the FortiGate which network is reachable via the tunnel interface.
Is configured under Network > Static Routes.
Does not control whether traffic is allowed; it only directs traffic path.
Firewall Policy for VPN
Decides whether to permit or deny traffic flowing into or out of the tunnel interface.
Is configured under Policy & Objects > Firewall Policy.
Controls security; even with a correct route, no traffic flows without a policy.
Mistake
I can have the same pre-shared key for my Phase 1 as my Phase 2.
Correct
The pre-shared key is only used in Phase 1 to authenticate the peers. Phase 2 does not use the pre-shared key; it derives new keys from the Diffie-Hellman exchange in Phase 1 using the parameters negotiated in Phase 2.
People conflate 'authentication' (Phase 1) with 'encryption' (Phase 2). They think the password for the tunnel covers everything, but the key generation process is separate.
Mistake
Once the Phase 1 tunnel is up, my VPN is working.
Correct
The Phase 1 tunnel being 'up' only means the control channel for negotiation is established. The actual data tunnel (Phase 2) must also be established to pass traffic. A tunnel can be up in Phase 1 but down in Phase 2 because of misconfigured traffic selectors or mismatched encryption methods.
Beginners see a 'green' status for the tunnel and assume everything is fine. They do not realise that a Phase 1 status does not guarantee that the specific data flows have been agreed upon.
Mistake
Site-to-Site VPN is the same as a Remote Access VPN, just with more users.
Correct
A Site-to-Site VPN connects entire networks (router to router), creating a permanent link. A Remote Access VPN connects individual end devices (like a laptop) to a network, typically on demand. The configuration, use case, and protocols (often SSL for remote access vs IPsec for site-to-site) are fundamentally different.
Both terms include 'VPN', so people incorrectly group them together. They miss the architectural difference: one is network-to-network, the other is host-to-network.
Mistake
IKEv2 is just an update to IKEv1 and behaves the same way.
Correct
IKEv2 is a completely re-engineered protocol. It requires fewer exchanges (two for Phase 1 instead of potentially six with main mode in IKEv1), is more efficient, and has built-in features like NAT traversal and dead peer detection that needed to be added as supplementary RFCs for IKEv1. IKEv2 is also more resilient to changes in network conditions.
People assume 'version 2' means 'version 1 with a few bug fixes'. They do not appreciate the architectural improvements, leading them to misconfigure settings that are only relevant to one version.
Mistake
A firewall policy is not needed if the VPN tunnel is configured correctly.
Correct
A FortiGate will always check its firewall policy before allowing traffic through the tunnel interface. Even if the VPN tunnel is perfectly configured and up, without a policy allowing traffic from the local LAN to the tunnel interface (and back), traffic will be dropped. The tunnel and the firewall are separate security layers.
Beginners focus solely on the VPN configuration and forget the fundamental principle of stateful firewalling: all traffic must be permitted by a policy. They see the tunnel as an open 'pipe,' not as a logical interface subject to rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The most common causes are a mismatch in the pre-shared key, a mismatch in Phase 1 parameters (like encryption algorithm), or incorrect remote gateway IP address. Check the logs on both FortiGates for specific error messages.
IKEv2 is more modern and efficient. It requires fewer message exchanges to set up the tunnel, has built-in support for NAT traversal and Dead Peer Detection, and is more resilient to network changes. IKEv1 is older and more complex, with options like Main Mode and Aggressive Mode.
Traffic selectors (also called Proxy-IDs) define which source and destination IP addresses or subnets are allowed to communicate through the VPN tunnel. If they do not match on both sides, Phase 2 will fail.
This is usually due to one of two issues: a missing or incorrect static route on either side, or a missing firewall policy that denies the traffic. Check the routing table and the policy list on both FortiGates.
You've finished Site-to-Site IPsec VPNs. Continue through the NSE4 study guide to build a complete picture of the exam.
Done with this chapter?