VPNs (Virtual Private Networks) secure communications over public or private networks, ensuring data confidentiality and integrity. Below is a beginner-friendly, detailed explanation of VPN concepts and configurations.
IPsec VPN provides secure, encrypted tunnels for site-to-site or remote access communication.
Phase 1 (IKE Negotiation):
Establish a secure channel between peers for further negotiations.
Steps to configure:
config vpn ipsec phase1-interface
edit <Phase1_Name> # e.g., Site1_to_Site2
set interface <WAN_Interface> # e.g., port1
set proposal <encryption_algorithm> # e.g., aes256-sha256
set psksecret <PreSharedKey> # e.g., MySecretKey
set ike-version <1|2> # IKEv1 or IKEv2
set remote-gw <Remote_IP> # e.g., 203.0.113.10
set localid <Local_ID> # Optional for advanced use
set dhgrp <DH_Group> # e.g., 14 (2048-bit Diffie-Hellman)
end
Phase 2 (IPsec SA Negotiation):
Define encryption and authentication settings for data transmission.
Steps to configure:
config vpn ipsec phase2-interface
edit <Phase2_Name> # e.g., Site1_to_Site2_Phase2
set phase1name <Phase1_Name> # Link to Phase 1
set proposal <encryption_algorithm> # e.g., aes256-sha256
set pfs enable
set dhgrp <DH_Group> # e.g., 14
set src-subnet <Source_Network> # e.g., 192.168.1.0/24
set dst-subnet <Destination_Network> # e.g., 192.168.2.0/24
end
Firewall Policies:
Allow VPN traffic:
config firewall policy
edit 1
set srcintf <Internal_Interface>
set dstintf <VPN_Interface>
set srcaddr <Source_Subnet> # e.g., 192.168.1.0/24
set dstaddr <Destination_Subnet> # e.g., 192.168.2.0/24
set action accept
set schedule always
set service all
end
DPD ensures the VPN tunnel is re-established automatically if the remote peer becomes unreachable.
Enable DPD in Phase 1:
config vpn ipsec phase1-interface
edit <Phase1_Name>
set dpd enable
set dpd-retryinterval <Seconds> # e.g., 10
set dpd-retrycount <Retries> # e.g., 3
end
SSL VPN is ideal for remote users who need secure access to resources, offering both lightweight and full-tunnel options.
Web Mode:
Web mode provides browser-based access to internal resources such as file servers and applications.
Steps to configure:
config vpn ssl settings
set servercert <Certificate_Name> # e.g., FortiGate_SSL
set tunnel-ip-pools <IP_Pool_Name> # e.g., SSL_VPN_Pool
set source-interface <WAN_Interface>
set source-address <Allowed_Sources>
set default-portal <Portal_Name> # e.g., Web_Access
end
Tunnel Mode:
Tunnel mode provides full network connectivity through an SSL VPN client.
Steps to configure:
config vpn ssl settings
set tunnel-ip-pools <IP_Pool_Name>
set source-interface <WAN_Interface>
set source-address <Allowed_Sources>
set default-portal <Portal_Name>
end
Firewall Policies for SSL VPN Traffic:
Allow traffic between SSL VPN users and internal resources:
config firewall policy
edit 1
set srcintf ssl.root
set dstintf <LAN_Interface>
set srcaddr <SSL_VPN_Pool>
set dstaddr <Internal_Resources>
set action accept
set schedule always
set service all
end
Configure Local Users:
Add SSL VPN users to FortiGate:
config user local
edit <Username>
set type password
set passwd <Password>
end
Enable MFA (Multi-Factor Authentication):
Use FortiToken or third-party MFA providers:
config user local
edit <Username>
set two-factor enable
set fortitoken <Token_Serial_Number>
end
Centralized Communication:
Hub-and-spoke VPN connects multiple branch offices via a central hub (HQ).
Configure IPsec tunnels from each branch to the HQ:
config vpn ipsec phase1-interface
edit <Branch1_To_Hub>
set remote-gw <Branch1_IP>
end
Routing Traffic Through the Hub:
Dynamic Tunnel Creation:
ADVPN dynamically establishes tunnels between branch offices without routing all traffic through the hub.
Enable ADVPN:
config vpn ipsec phase1-interface
edit <Hub_Phase1>
set advpn enable
end
Configure Spokes:
Set ADVPN parameters on each branch:
config vpn ipsec phase1-interface
edit <Branch_Phase1>
set advpn enable
end
Optimize Bandwidth:
Route only critical traffic through the VPN and send non-essential traffic directly to the internet.
Enable split tunneling:
config vpn ssl settings
set split-tunneling enable
set split-tunneling-routing-address <Internal_Networks>
end
Proper administrative control ensures that only authorized personnel can access and perform actions on the FortiGate device. Fortinet allows granular role-based access using admin profiles.
To manage administrative access securely, it is a best practice to create unique accounts for each administrator. This enables audit tracking and role segregation.
config system admin
edit "admin_read"
set password YourSecurePassword
set accprofile "read-only"
set vdom "root"
end
edit sets the username.
set accprofile assigns the permission level (e.g., super_admin, read-only, or custom profile).
set vdom restricts access to a specific Virtual Domain.
You can define custom profiles that permit access to specific features or commands.
config system accprofile
edit "custom_admin"
set secfabgrp read-write
set loggrp read-only
set sysgrp read-only
end
This example allows full access to Security Fabric and limited access to logging and system settings.
To enhance security, you can configure automatic account lockout after a number of failed attempts.
config system global
set admin-lockout-threshold 3 # Number of failed attempts
set admin-lockout-duration 300 # Lockout duration in seconds
end
These settings prevent brute-force attempts by locking the user out temporarily.
Backing up configuration is a critical part of system maintenance and disaster recovery.
execute backup config flash mybackup.conf
This saves the current configuration file to the internal flash storage with the specified filename.
execute restore config flash mybackup.conf
This command restores a previously backed-up configuration file from the flash storage.
To TFTP:
execute backup config tftp mybackup.conf 192.168.1.10
To FTP:
execute backup config ftp mybackup.conf ftpserver 21 user password
These methods allow you to push configuration backups to a remote server for redundancy.
Firmware updates are important for performance improvements, security patches, and new features.
To manually upgrade firmware using a previously uploaded image:
execute restore image <image_file_name> <device_storage_location>
Or to trigger a system update (mainly for FortiGuard updates, but relevant in some cases):
execute update-now
In practice, most administrators use the Web GUI to:
Upload new firmware
Check for compatibility warnings
View system restore points
This process typically involves:
Navigating to System > Firmware
Choosing Upload Firmware or Check for Updates
Following prompts for reboot and backup
Always back up your configuration before an upgrade.
Verify the release notes for hardware compatibility and behavior changes.
Test new firmware in a lab environment for critical networks.
| Supplement Topic | Key Focus |
|---|---|
| Admin Profiles | Create accounts, assign access levels, enforce lockout security |
| Configuration Backup | Use execute backup and execute restore for local or remote storage |
| Firmware Upgrade | Manage via CLI or GUI; ensure compatibility and create backups |
In many real-world deployments, IPsec VPN peers are located behind NAT devices. Standard IPsec encapsulation using ESP (IP protocol 50) cannot pass through NAT without special handling. To solve this, NAT Traversal (NAT-T) encapsulates IPsec traffic inside UDP port 4500, making it compatible with NAT environments.
config vpn ipsec phase1-interface
edit "Site1_to_Site2"
set interface "wan1"
set remote-gw "203.0.113.10"
set psksecret "MySecretKey"
set ike-version 2
set nat-traversal enable
end
When nat-traversal is enabled, FortiGate automatically detects NAT and switches to UDP-encapsulated IPsec if necessary.
Common exam scenarios involve IPsec peers behind NAT or public cloud edge devices. Questions may ask:
What allows IPsec to work behind NAT?
Which setting ensures IPsec negotiation can traverse NAT gateways?
Answer: set nat-traversal enable
Tunnel Mode SSL VPN requires an actual software client on the user device to establish a virtual interface for full network access. FortiClient is Fortinet’s official SSL VPN client.
Supports two-factor authentication (e.g., FortiToken).
Automatically pulls tunnel settings from FortiGate.
Compatible with Windows, macOS, iOS, Android.
CLI/GUI configuration remains the same, but the end user must install and configure FortiClient.
In Web Mode, users access internal resources via a web portal. Admins can define Bookmarks, which are predefined links or access points for:
Internal websites
RDP/SSH connections
SMB shares
Example configuration (GUI-based):
Navigate to: VPN > SSL-VPN Portals
Under Bookmarks, define type (HTTP, SMB, etc.), target address, and access credentials if needed.
While portal bookmarks are rarely tested directly, knowing the difference between Web Mode and Tunnel Mode and how access is granted in each is crucial.
ADVPN (Auto-Discovery VPN) dynamically establishes spoke-to-spoke tunnels without routing all traffic through the hub. For this to function efficiently, routing updates between branches must occur—and that’s where BGP or OSPF comes in.
Hub: Central FortiGate with ADVPN and dynamic routing enabled.
Spokes: FortiGates configured with ADVPN and a routing protocol to learn about each other’s internal subnets.
Routing example (OSPF on each branch):
config router ospf
config network
edit 1
set prefix 192.168.10.0 255.255.255.0
set area 0.0.0.0
end
end
Split Tunneling allows users to send only specific traffic (e.g., destined for the company network) through the VPN tunnel, while all other internet-bound traffic is routed via the local ISP.
A remote user connects via SSL VPN:
Accesses internal systems (e.g., 10.0.0.0/8) through the VPN.
Continues to use their local network for web browsing or streaming.
config vpn ssl settings
set split-tunneling enable
set split-tunneling-routing-address "Internal_Networks"
end
Improves bandwidth usage.
Enhances performance.
Reduces unnecessary load on the FortiGate.
Often tested with questions like: “How can you ensure only certain destinations go through the VPN?”
| Topic | Key Concept | Command / Example |
|---|---|---|
| NAT Traversal (IPsec) | Enables IPsec to function behind NAT devices | set nat-traversal enable in Phase 1 config |
| FortiClient (SSL Tunnel Mode) | Required client software for full-tunnel SSL VPN access | User installs and connects via FortiClient |
| Portal Bookmarks (Web Mode) | Web-access links to internal apps in SSL VPN | Configured under SSL-VPN Portals in GUI |
| ADVPN + Dynamic Routing | BGP or OSPF is used to propagate spoke subnets for tunnel discovery | Add OSPF/BGP between spokes and hub |
| Split Tunneling Use Case | Route internal traffic via VPN; internet traffic via local gateway | set split-tunneling enable with routing-address |
Why can spokes reach the hub but not communicate with each other in an ADVPN deployment?
The most common reason is that ADVPN shortcut tunnels are not being dynamically established between spokes.
In an ADVPN topology, all spokes initially communicate through the hub. When traffic between spokes is detected, the hub coordinates the creation of a direct IPsec shortcut tunnel between them. If spokes can reach the hub but not each other, it usually means shortcut negotiation failed. Common causes include missing ADVPN settings in Phase 1, incorrect routing configuration (BGP/OSPF), firewall policies blocking spoke-to-spoke traffic, or NAT interfering with the overlay network. Another frequent mistake is failing to allow dynamic tunnels in the hub configuration. Without the shortcut, traffic must traverse the hub, and if routing policies prevent that path, the communication fails.
Demand Score: 92
Exam Relevance Score: 91
What requirements must be met before deploying ADVPN on FortiGate devices?
ADVPN requires interface-based IPsec VPN tunnels using IKEv2 and dynamic routing such as BGP or OSPF.
ADVPN works by dynamically creating shortcut tunnels between spokes in a hub-and-spoke topology. For this to function properly, the VPN must be configured as an interface-based tunnel rather than policy-based. IKEv2 is typically required because it supports the necessary dynamic negotiation features used by ADVPN. Dynamic routing protocols such as BGP or OSPF are also recommended so routing information can automatically update when shortcuts are created. Without dynamic routing, spokes may continue sending traffic through the hub because the routing table never learns about the new direct path. Ensuring consistent configuration across hub and spokes is critical for ADVPN stability.
Demand Score: 84
Exam Relevance Score: 89
What is the purpose of ADVPN shortcut tunnels in a hub-and-spoke network?
ADVPN shortcut tunnels allow spokes to establish direct IPsec tunnels with each other, bypassing the hub.
In a traditional hub-and-spoke VPN, all traffic between branch offices must travel through the hub firewall, which increases latency and load on the hub device. ADVPN solves this by dynamically creating direct tunnels between spokes when traffic between them is detected. Initially, packets flow through the hub, but the hub then coordinates the creation of a shortcut tunnel. Once established, routing updates redirect traffic directly between the spokes. This reduces latency, decreases hub processing overhead, and improves overall network efficiency. The hub still acts as a control point for authentication and shortcut negotiation.
Demand Score: 75
Exam Relevance Score: 87
Why is dynamic routing commonly used with ADVPN deployments?
Dynamic routing allows automatic route updates when ADVPN shortcut tunnels are created.
When a new shortcut tunnel forms between spokes, the network topology effectively changes because a new path becomes available. If static routes were used, traffic might still follow the original path through the hub even though a better direct route exists. Dynamic routing protocols like BGP or OSPF automatically update the routing table when new interfaces or paths appear. This allows spokes to quickly learn that a direct tunnel is available and reroute traffic accordingly. Dynamic routing also improves failover behavior, ensuring traffic can revert to hub-based routing if the shortcut tunnel fails.
Demand Score: 78
Exam Relevance Score: 86
What troubleshooting steps should be performed when ADVPN shortcuts are not forming?
Verify Phase 1 ADVPN settings, dynamic routing configuration, firewall policies, and debug logs.
When shortcut tunnels fail to establish, administrators should first confirm that ADVPN is enabled in the IPsec Phase 1 configuration and that the hub is configured to support shortcut negotiation. Next, verify that routing protocols like BGP or OSPF are correctly exchanging routes between spokes. Firewall policies must allow traffic between spoke subnets across the VPN interface. If configuration appears correct, debugging commands such as diagnose vpn tunnel list or ADVPN-related logs can help determine whether the hub is attempting shortcut negotiation. Logs often reveal whether routing, security policies, or VPN parameters are preventing tunnel establishment.
Demand Score: 85
Exam Relevance Score: 88
In an ADVPN design, what role does the hub firewall play once shortcuts are established?
The hub acts as a control and initial routing point but no longer carries spoke-to-spoke traffic.
When the network first starts, all spokes communicate through the hub because no direct tunnels exist. After traffic between two spokes is detected, the hub coordinates the negotiation of a direct shortcut tunnel between them. Once that tunnel is established and routing updates occur, traffic flows directly between the spokes without passing through the hub. The hub still maintains the hub-and-spoke topology for management and authentication purposes, but it is removed from the data path for those spoke-to-spoke communications. This design greatly reduces hub bandwidth usage and improves performance for branch-to-branch traffic.
Demand Score: 72
Exam Relevance Score: 84