Virtual Private Networks (VPNs) enable secure communication over public or private networks. FortiGate supports multiple VPN types, including IPsec VPN, SSL VPN, and Auto-Discovery VPN (ADVPN).
IPsec VPNs are commonly used for secure, encrypted communication between two networks (site-to-site) or between a remote device and a network.
Purpose:
Configuration Components:
Configuration Steps:
Phase 1 Setup:
config vpn ipsec phase1-interface
edit "Site-to-Site"
set interface "port1"
set peertype any
set proposal aes256-sha256
set psksecret "YourPSK"
set remote-gw 203.0.113.1
next
end
Phase 2 Setup:
config vpn ipsec phase2-interface
edit "P2-Site-to-Site"
set phase1name "Site-to-Site"
set proposal aes256-sha256
set src-subnet 192.168.1.0/24
set dst-subnet 192.168.2.0/24
next
end
Create Policies:
config firewall policy
edit 1
set srcintf "port1"
set dstintf "port2"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
Why IKEv2?
How to Enable IKEv2:
Add the following to the Phase 1 configuration:
set ike-version 2
SSL VPN provides secure remote access to corporate networks. It is easier to configure for end users than IPsec VPN and operates over HTTPS.
Web Mode:
Tunnel Mode:
Configuration Steps:
Enable SSL VPN:
config vpn ssl settings
set servercert "Fortinet_Factory"
set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
set port 443
end
Configure User Access:
config user local
edit "remote-user"
set type password
set passwd "SecurePassword"
next
end
Create SSL Policies:
config firewall policy
edit 2
set srcintf "ssl.root"
set dstintf "port2"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
next
end
LDAP Integration:
Authenticate users using a corporate LDAP server.
Example configuration:
config user ldap
edit "LDAP_Server"
set server "192.168.1.10"
set cnid "uid"
set dn "dc=example,dc=com"
next
end
RADIUS Integration:
Use a RADIUS server for user authentication.
config user radius
edit "RADIUS_Server"
set server "192.168.1.20"
set secret "RADIUS_Secret"
next
end
ADVPN simplifies VPN setup by dynamically creating tunnels between branch offices when needed.
How It Works:
Configuration Steps:
Enable ADVPN in the hub:
config vpn ipsec phase1-interface
edit "Hub-ADVPN"
set net-device enable
set add-route enable
set proposal aes256-sha256
set remote-gw 0.0.0.0
next
end
Enable dynamic tunnels in the branches:
config vpn ipsec phase1-interface
edit "Branch-ADVPN"
set net-device enable
set add-route enable
set proposal aes256-sha256
set remote-gw 192.168.1.1
next
end
Why Use FortiManager?
How to Configure VPNs in FortiManager:
Here’s how VPN features might be applied in a real-world scenario:
VPNs are crucial for secure communication in both small and large networks. By mastering IPsec, SSL, and ADVPN configurations, you can build flexible and secure remote access solutions for any organization.
Key Characteristics:
vpn-to-siteA) for the IPsec tunnel.Configuration Steps:
srcintf or dstintf.Use Case:
Key Characteristics:
Configuration Steps:
action ipsec.Use Case:
| Feature | Route-Based VPN | Policy-Based VPN |
|---|---|---|
| Interface Created | Yes (e.g., vpn-to-siteA) | No |
| Routing Method | Static/dynamic routes | Policy-defined |
| Flexibility | High | Low |
| Modern Best Practice | Yes | No |
| Fortinet Exam Coverage | Frequently tested | Frequently tested |
diagnose vpn ike gateway list
get vpn ipsec tunnel details
diagnose debug application ike -1
diagnose debug enable
diagnose debug reset
You may encounter a question like:
“You configured a VPN tunnel, but traffic is not passing. Which command helps verify Phase 2 selectors?”
Correct answer: get vpn ipsec tunnel details
Split tunneling allows only specified traffic (e.g., internal subnet 10.0.0.0/24) to go through the SSL VPN tunnel, while all other traffic (e.g., general internet access) stays local.
config vpn ssl web portal
edit "tunnel-access"
set tunnel-mode enable
set split-tunneling enable
set ip-pools "SSLVPN_TUNNEL_ADDR1"
set split-tunneling-routing-address "LAN-SUBNET"
next
end
To secure remote access via SSL VPN, Fortinet recommends several hardening techniques, which are also commonly tested in the exam.
| Topic | Key Point |
|---|---|
| Route-based vs Policy-based VPN | Route-based preferred; policy-based is legacy but still exam-tested |
| IPsec VPN Diagnostics | Use CLI to verify Phase 1/2 status and troubleshoot negotiation issues |
| SSL VPN Split Tunneling | Allows partial traffic to go through VPN while keeping local access open |
| SSL VPN Security Best Practices | 2FA, access restriction, local subnet block, TLS hardening |
Why can I connect to a remote-access IPsec VPN but still be unable to ping or reach devices on the LAN?
Because tunnel establishment alone does not prove that selectors, routes, and post-auth policy handling are correct.
A recent Fortinet Community thread shows this exact symptom: the user connects successfully, but LAN access fails. That usually means Phase 1 came up, yet the traffic definition or forwarding logic is still wrong. The engineer should verify the Phase 2 selectors, assigned address space, relevant routes, and firewall policies for VPN-to-LAN traffic. A common mistake is assuming that broad selectors like 0.0.0.0/0 automatically make access work cleanly; in practice, overly broad or mismatched selectors can complicate troubleshooting. The exam lesson is important: “VPN is up” only confirms negotiation, not end-to-end reachability. Strong answers separate control-plane success from data-plane success and then check selectors, routing, and policy in that order.
Demand Score: 93
Exam Relevance Score: 95
Why would a GRE-over-IPsec or site-to-site VPN tunnel stay down even when both sides appear to be configured the same?
Because “looks identical” is not enough; negotiation, peer identity, reachability, and routing must all line up for the encapsulated traffic to work.
The GRE-over-IPsec case from the Fortinet forum is a good reminder that visual config comparison often misses the real problem. Even when both phases appear equivalent, tunnel establishment can still fail because of peer expectations, negotiation details, intermediate path changes, or routing around the tunnel interface. Another related symptom appears when traffic never actually leaves the FortiGate through the VPN despite the tunnel object existing. The exam-relevant mindset is structured troubleshooting: first prove IKE/IPsec negotiation, then confirm tunnel-interface state, then validate routes and policy for the protected traffic. Engineers often jump straight into rewriting the config when the real issue is forwarding or phase matching. Good answers stay methodical and avoid assuming that “same config on both ends” guarantees interoperable behavior.
Demand Score: 86
Exam Relevance Score: 87
How should I think about split tunnel when I want only specific FQDNs or public destinations to use the VPN?
Treat it as a routing and traffic-steering design problem, not just a checkbox called split tunnel.
Recent Reddit questions show admins trying to send only selected FQDNs or vendor portals through the FortiClient tunnel while leaving general Internet access local. That demand signal matters because it is exactly where many designs become fragile. FQDN-based intent sounds simple, but actual steering still depends on how the client resolves and routes those destinations. If the design goal is “only certain destinations use VPN,” the engineer must think about route injection, selector scope, and whether the chosen objects reliably match changing destination IPs. The exam takeaway is that split tunneling is not binary. The real challenge is aligning user intent, route distribution, and policy control so the desired traffic goes into the tunnel consistently without accidentally hairpinning everything else.
Demand Score: 88
Exam Relevance Score: 83
What usually goes wrong when migrating from SSL-VPN to dial-up IPsec with SAML, especially on dual-WAN setups?
The difficult part is not basic tunnel creation; it is aligning SAML, IKEv2 behavior, client support, and path selection across multiple uplinks.
This is a strong current demand cluster because many admins are reevaluating SSL-VPN and moving toward IPsec-based remote access. Fortinet documentation confirms that SAML-based authentication for FortiClient remote-access dial-up IPsec is supported with IKEv2, and community posts show real issues emerging when dual-WAN is added to the design. That combination introduces more moving parts: identity flow, return-path symmetry, tunnel selection, and client behavior during TCP-heavy sessions. For the exam, the smart answer is not “SAML is broken,” but “this design adds dependencies beyond simple credentials.” When remote-access VPN uses SAML plus dual WAN, you must validate authentication flow, chosen uplink, and the traffic return path together. That design awareness is much closer to how the exam frames enterprise troubleshooting.
Demand Score: 84
Exam Relevance Score: 92
What is the practical concern with IPsec dial-up users coming from IPv6-only ISPs, and why is this becoming more important?
Because an IPv4-only remote-access design may fail for users whose providers no longer give them usable public IPv4 connectivity.
A recent Fortinet Community thread describes exactly this problem: the existing SAML-based IPsec dial-up works over IPv4, but more users are appearing behind IPv6-only access networks. That pushes VPN design from “it works in the lab” to “it works for the real Internet edge users have today.” Community and documentation sources also show that Fortinet’s remote-access IPsec/SAML feature set continues evolving, which makes dual-stack awareness more relevant operationally. On the exam, the important concept is not memorizing one specific command. It is recognizing that remote-access VPN reliability depends on client access conditions outside the firewall too. A design that assumes universal IPv4 may be functionally incomplete for a growing slice of users, so migration planning must include transport assumptions, not just authentication and policy.
Demand Score: 80
Exam Relevance Score: 78