Shopping cart

Subtotal:

$0.00

NSE7_EFW-7.2 VPN

VPN

Detailed list of NSE7_EFW-7.2 knowledge points

VPN Detailed Explanation

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).

5.1 IPsec VPN

IPsec VPNs are commonly used for secure, encrypted communication between two networks (site-to-site) or between a remote device and a network.

5.1.1 Site-to-Site VPN

  • Purpose:

    • Connects two networks securely over the internet.
    • Often used between a corporate office and a branch office.
  • Configuration Components:

    1. Phase 1 (IKE Negotiation):
      • Establishes a secure connection between the two endpoints.
      • Defines encryption (e.g., AES256) and authentication (e.g., SHA256) methods.
    2. Phase 2 (IPsec Tunnel):
      • Defines the traffic to be encrypted and additional encryption parameters.
  • Configuration Steps:

    1. 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
      
    2. 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
      
    3. Create Policies:

      • Allow traffic between source and destination subnets.
      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
      

5.1.2 IKEv2

  • Why IKEv2?

    • Faster key exchange, better reliability, and support for NAT traversal.
  • How to Enable IKEv2:

    • Add the following to the Phase 1 configuration:

      set ike-version 2
      

5.2 SSL VPN

SSL VPN provides secure remote access to corporate networks. It is easier to configure for end users than IPsec VPN and operates over HTTPS.

5.2.1 Web Mode and Tunnel Mode

  • Web Mode:

    • Provides browser-based access to specific resources (e.g., file servers or intranet applications).
    • Ideal for users needing limited access.
  • Tunnel Mode:

    • Creates a secure tunnel for full network access.
    • Suitable for employees requiring extensive access to corporate resources.
  • Configuration Steps:

    1. Enable SSL VPN:

      config vpn ssl settings
         set servercert "Fortinet_Factory"
         set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
         set port 443
      end
      
    2. Configure User Access:

      • Create SSL VPN users in the local database or integrate with LDAP/RADIUS.
      config user local
         edit "remote-user"
             set type password
             set passwd "SecurePassword"
         next
      end
      
    3. 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
      

5.2.2 User Authentication

  • 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
      

5.3 Auto-Discovery VPN (ADVPN)

ADVPN simplifies VPN setup by dynamically creating tunnels between branch offices when needed.

5.3.1 Dynamic Tunnel Creation

  • How It Works:

    • In traditional VPNs, all traffic is routed through a central hub, which may cause latency.
    • ADVPN allows branch offices to establish direct tunnels dynamically, bypassing the hub.
  • Configuration Steps:

    1. 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
      
    2. 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
      

5.3.2 Centralized Management

  • Why Use FortiManager?

    • FortiManager can automate VPN configurations across multiple sites, saving time in large deployments.
  • How to Configure VPNs in FortiManager:

    1. Add devices to FortiManager.
    2. Create a VPN community that includes hub and branch devices.
    3. Deploy the VPN configurations to all devices automatically.

Practical Example Workflow

Here’s how VPN features might be applied in a real-world scenario:

  1. IPsec VPN:
    • Securely connect a branch office to the main office for shared file access.
  2. SSL VPN:
    • Enable remote employees to access corporate resources securely from home.
  3. ADVPN:
    • Allow two branch offices to communicate directly for faster collaboration.

Why VPNs are Important

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.

VPN (Additional Content)

1. Route-Based VPN vs Policy-Based VPN

Route-Based VPN (Interface-Based) – Default and Recommended

Key Characteristics:

  • Creates a virtual interface (e.g., vpn-to-siteA) for the IPsec tunnel.
  • Routing decisions are made based on the routing table.
  • Offers greater flexibility and better integration with:
    • SD-WAN
    • Advanced routing (OSPF/BGP)
    • Diagnostics and monitoring tools

Configuration Steps:

  • Create a Phase 1 interface.
  • Create a Phase 2 selector.
  • Add static routes or dynamic protocols pointing to the tunnel interface.
  • Apply firewall policies using the tunnel interface as srcintf or dstintf.

Use Case:

  • Complex enterprise networks, dynamic routing, or multiple tunnels.

Policy-Based VPN – Legacy Style

Key Characteristics:

  • No virtual interface is created.
  • VPN configuration is tied directly to a firewall policy.
  • Phase 1 and Phase 2 selectors are invoked by the policy itself.
  • Less flexible, not recommended for modern deployments.

Configuration Steps:

  • Define Phase 1 and Phase 2 as non-interface based.
  • Create a policy with action ipsec.
  • Define source, destination, and services in the policy.

Use Case:

  • Simple point-to-point connections with fixed policies and no dynamic routing.

Comparison Table:

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

2. IPsec VPN Diagnostics – CLI Troubleshooting Commands

View Phase 1 Tunnel Status:

diagnose vpn ike gateway list
  • Displays tunnel name, status, remote IP, and current phase 1 status.

View Phase 2 Security Associations:

get vpn ipsec tunnel details
  • Shows encryption details, selectors, byte counters, and tunnel uptime.

Debug IKE Negotiation:

diagnose debug application ike -1
diagnose debug enable
  • Enables verbose output for Phase 1 and Phase 2 negotiations.
  • Use with caution in production—can generate large outputs.

Stop Debugging:

diagnose debug reset

Exam Tip:

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

3. SSL VPN Split Tunneling

What Is Split Tunneling?

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.

Why Use It?

  • Reduces load on the FortiGate VPN gateway.
  • Improves internet performance for remote users.
  • Enhances security by limiting VPN access scope.

How to Enable:

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
  • Ensure that your firewall policy only allows specific subnets for split tunneling.

4. SSL VPN Security Best Practices

To secure remote access via SSL VPN, Fortinet recommends several hardening techniques, which are also commonly tested in the exam.

1. Enforce Two-Factor Authentication (2FA):

  • Add a second authentication factor (e.g., FortiToken or external RADIUS with OTP).
  • Applied via user group settings.

2. Block Access to Local Subnets (Prevent VPN Pivoting):

  • Prevent connected SSL VPN users from accessing their local subnet.
  • Achieved by modifying the split tunneling settings or using deny policies.

3. Limit Access to Internal Resources:

  • Use address groups or firewall policies to restrict SSL VPN users to only the necessary services or subnets.

4. Use Secure TLS Settings:

  • Disable legacy TLS versions (TLS 1.0 / 1.1).
  • Use strong ciphers only.

5. Regularly Rotate Certificates and Keys:

  • Avoid long-term self-signed certificates.
  • Ensure VPN servers use up-to-date, trusted certificates.

Summary Table:

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

Frequently Asked Questions

Why can I connect to a remote-access IPsec VPN but still be unable to ping or reach devices on the LAN?

Answer:

Because tunnel establishment alone does not prove that selectors, routes, and post-auth policy handling are correct.

Explanation:

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?

Answer:

Because “looks identical” is not enough; negotiation, peer identity, reachability, and routing must all line up for the encapsulated traffic to work.

Explanation:

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?

Answer:

Treat it as a routing and traffic-steering design problem, not just a checkbox called split tunnel.

Explanation:

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?

Answer:

The difficult part is not basic tunnel creation; it is aligning SAML, IKEv2 behavior, client support, and path selection across multiple uplinks.

Explanation:

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?

Answer:

Because an IPv4-only remote-access design may fail for users whose providers no longer give them usable public IPv4 connectivity.

Explanation:

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

NSE7_EFW-7.2 Training Course