Home

Mastering L2TP over IPsec VPN Configuration on FortiGate: A Comprehensive Implementation Guide

.

Layer 2 Tunneling Protocol (L2TP) combined with IPsec encryption provides organizations with a native, clientless remote access solution compatible with Windows, macOS, and Linux operating systems. Unlike SSL VPN solutions requiring dedicated clients like FortiClient, L2TP/IPsec leverages built-in OS capabilities while maintaining enterprise-grade security through IPsec encryption. This guide delivers authoritative, step-by-step configuration instructions for FortiGate administrators implementing robust L2TP/IPsec infrastructure across policy-based and route-based architectures, with critical attention to NAT traversal, authentication integration, and troubleshooting methodologies.

Understanding L2TP/IPsec Architecture on FortiGate

Core Technical Foundation

L2TP itself provides tunneling capabilities but lacks native encryption. FortiGate implementations address this security gap by encapsulating L2TP traffic within IPsec tunnels, creating a dual-layer security model where:

  • IPsec Phase 1 establishes the secure management channel using IKE (Internet Key Exchange)
  • IPsec Phase 2 creates the data tunnel with L2TP specifically enabled
  • Transport mode (not tunnel mode) is mandatory for L2TP/IPsec compatibility
  • UDP port 1701 carries L2TP traffic, while IPsec uses UDP 500 (IKE) and UDP 4500 (NAT-T)

This architecture enables Windows native clients, macOS built-in VPN, and Linux NetworkManager to connect without third-party software—critical for BYOD environments and contractor access scenarios where client deployment faces organizational constraints.

Critical Prerequisites and Requirements

Before initiating configuration, verify these foundational requirements:

Requirement Specification Verification Method
FortiGate Mode NAT/Route mode with static public IP address System > Dashboard > Status
FortiOS Version 5.4+ (policy-based); 6.2+ recommended for route-based System > Dashboard > Status
Firewall Rules Allow UDP 1701 (L2TP), UDP 500/4500 (IPsec) Policy & Objects > IPv4 Policy
NAT Traversal Required when FortiGate sits behind NAT devices Phase 1 configuration: set nattraversal enable
Windows Clients Windows 7+ with IPsec Services running (Automatic startup) Services.msc > IPsec Policy Agent
macOS/Linux Built-in L2TP/IPsec client support Native OS network settings

Note: L2TPv3 is explicitly unsupported on all FortiOS versions

Configuration Methodologies: Policy-Based vs. Route-Based

Policy-Based L2TP/IPsec (Traditional Approach)

Policy-based configuration remains the most documented approach in Fortinet documentation and suits environments requiring granular traffic control through security policies.

Step 1: Create Authentication Infrastructure

# Create local user account config user local     edit "vpnuser"         set type password         set passwd "SecureP@ssw0rd!"     next end  # Create user group for L2TP access config user group     edit "L2TP_Group"         set member "vpnuser"     next end

Alternative: Integrate with RADIUS/LDAP/TACACS+ servers under User & Authentication > Authentication Servers for centralized credential management

Step 2: Enable L2TP Service (CLI-Only Configuration)

config vpn l2tp     set sip 10.20.100.1          # Start IP for client pool     set eip 10.20.100.100        # End IP for client pool     set status enable     set usrgrp "L2TP_Group"      # Link to authentication group     set enforce-ipsec-interface enable  # Critical security hardening end

Security Note: The enforce-ipsec-interface enable parameter forces encrypted connections only, preventing unencrypted L2TP attempts

Step 3: Configure IPsec Phase 1 (Policy-Based)

config vpn ipsec phase1     edit "l2tp-p1"         set type dynamic          # Required for remote access         set interface "wan1"      # Public-facing interface         set mode main         set peertype dialup         set proposal aes256-sha1 3des-sha1 aes192-sha1         set dhgrp 2               # Diffie-Hellman Group 2         set keylife 86400         # 24-hour key lifetime         set nattraversal enable   # Mandatory for NAT environments         set dpd on-idle           # Dead Peer Detection         set psksecret "YourPreSharedKey!"  # Must match client configuration         set usrgrp "L2TP_Group"     next end

Step 4: Configure IPsec Phase 2 with L2TP Integration

config vpn ipsec phase2     edit "l2tp-p2"         set phase1name "l2tp-p1"         set proposal aes256-sha1 3des-sha1 aes192-sha1         set pfs disable           # Perfect Forward Secrecy typically disabled         set keylifeseconds 3600         set encapsulation transport-mode  # Critical: NOT tunnel-mode         set l2tp enable           # Explicit L2TP activation     next end

Step 5: Create Required Firewall Policies

Two policies are mandatory for functional connectivity:

Policy A: IPsec Tunnel Policy

Incoming Interface: Internal LAN (e.g., port2) Source Address: all Outgoing Interface: WAN (e.g., port1) Destination Address: all Action: IPSEC VPN Tunnel: l2tp-p1 (Phase 1 name)

Policy B: Client Access Policy

Incoming Interface: WAN (port1) Source Address: L2TP_Clients (address object matching client pool) Outgoing Interface: Internal LAN (port2) Destination Address: all Action: ACCEPT NAT: Enable (for internet access via FortiGate)

GUI Path: System > Feature Visibility > Enable "Policy-based IPsec VPN" before creating policies

Route-Based L2TP/IPsec (Modern Implementation)

Route-based configuration offers superior administrative flexibility and aligns with Fortinet's architectural direction. Critical differentiators include:

  • Uses virtual tunnel interfaces (l2t.root) instead of policy binding
  • Requires net-device enable in Phase 1 for multi-client NAT support
  • Simplifies policy management with standard interface-to-interface rules
  • Essential for WAN load balancing scenarios in FortiOS 5.2-7.0

Critical CLI Configuration Differences

# Phase 1 uses phase1-interface (not phase1) config vpn ipsec phase1-interface     edit "L2TP_RouteBased"         set type dynamic         set interface "wan1"         set net-device enable    # Required for multiple clients behind NAT         set proposal aes256-sha256         set psksecret "SecureKey!"     next end  # Phase 2 uses phase2-interface (not phase2) config vpn ipsec phase2-interface     edit "L2TP_p2"         set phase1name "L2TP_RouteBased"         set l2tp enable         set encapsulation transport-mode     next end  # Firewall policies reference virtual interface "l2t.root" config firewall policy     edit 0         set name "L2TP_to_LAN"         set srcintf "l2t.root"   # Virtual L2TP interface         set dstintf "internal"         set srcaddr "all"         set dstaddr "all"         set action accept         set service "ALL"     next end

Upgrade Warning: After upgrading from FortiOS 6.4.x/7.0.0 to 7.0.1+, manual configuration updates are required for L2TP/IPsec functionality

Client Configuration Best Practices

Windows Native Client Setup

  1. Network Settings > VPN > Add VPN Connection

    • VPN Provider: Windows (built-in)
    • Connection Name: Corporate L2TP
    • Server Name: FortiGate public IP/FQDN
    • VPN Type: L2TP/IPsec with pre-shared key
    • Pre-shared Key: Match FortiGate Phase 1 configuration
    • Sign-in Info: Username/password from FortiGate user database

  2. Critical Registry Modification (Windows clients behind NAT):

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters Create DWORD: ProhibitIpSec = 0

    This enables NAT-T functionality required when FortiGate resides behind NAT

  3. Service Verification:

    • IPsec Policy Agent: Startup Type = Automatic, Status = Running
    • Base Filtering Engine: Startup Type = Automatic, Status = Running

macOS and Linux Configuration

  • macOS: System Preferences > Network > + > Interface: VPN > VPN Type: L2TP over IPSec
  • Linux: NetworkManager > + > Layer 2 Tunneling Protocol (L2TP)
  • Both require identical pre-shared key and user credentials as Windows clients
  • FortiOS 4.0 MR3+ supports Mac OS X connections with empty AVP host names

Advanced Implementation Scenarios

RADIUS Authentication Integration

For enterprise environments requiring centralized authentication:

  1. Configure RADIUS server under User & Authentication > Authentication Servers
  2. Create user group with RADIUS server as member (not local users)
  3. Reference RADIUS group in both:
    • config vpn l2tp → set usrgrp "RADIUS_Group"
    • Phase 1 configuration → set usrgrp "RADIUS_Group"
  4. For Microsoft NPS integration with Active Directory:
    • Enable MS-CHAPv2 on NPS policies
    • Critical limitation: Azure AD-synced users cannot authenticate using MS-CHAPv2

Split Tunneling Configuration

FortiOS does not natively support split tunneling for L2TP/IPsec through client-side configuration. Implementation requires:

  1. Full Tunnel Approach (Default): All client traffic routes through FortiGate
  2. Policy-Based Split Tunneling: Create multiple firewall policies with specific destination addresses:
    • Policy 1: l2t.root → internal for corporate resources
    • Policy 2: l2t.root → wan1 with NAT enabled for internet access
  3. Client-Side Workaround: Manually add static routes on client devices post-connection (not recommended for scalability)

NAT Traversal Imperatives

When FortiGate resides behind another NAT device (common in cloud deployments):

  • Mandatory: Enable NAT-T in Phase 1 (set nattraversal enable)
  • Critical: Both FortiGate and client must have matching NAT-T settings
  • Limitation without net-device: Only one L2TP client can connect from behind the same NAT device unless net-device enable is configured
  • UDP 4500: NAT-T encapsulates IPsec in UDP 4500 to traverse NAT devices

Troubleshooting Methodology

Diagnostic Command Sequence

# Verify L2TP service status diagnose vpn l2tp status  # Check IPsec tunnel establishment diagnose vpn tunnel list  # Monitor real-time L2TP negotiation diagnose debug application ike -1 diagnose debug enable  # Restart L2TP daemon (temporary fix for stuck connections) fnsysctl killall l2tpd

Common Failure Scenarios and Resolutions

Symptom Root Cause Resolution
IPsec tunnel fails to establish Mismatched pre-shared keys Verify identical PSK on FortiGate Phase 1 and client
L2TP negotiation fails after IPsec up Transport mode not enabled in Phase 2 set encapsulation transport-mode required
Connection drops after 5 minutes Dead Peer Detection mismatch Set dpd on-idle in Phase 1; verify client DPD settings
Multiple clients fail behind same NAT net-device disabled in route-based config Enable set net-device enable in Phase 1-interface
Windows clients fail with error 789 IPsec Services not running Set IPsec Policy Agent startup to Automatic; restart service
Authentication succeeds but no connectivity Missing firewall policy for L2TP clients Create policy with source = L2TP client address range

Reference: Fortinet KB article "L2TP in IPsec connectivity issues" provides detailed diagnostics for Windows client failures

Security Hardening Recommendations

  1. Enforce IPsec Encryption: Always enable set enforce-ipsec-interface enable to prevent unencrypted L2TP connections
  2. Strong Cryptographic Proposals: Prefer AES256-SHA256 over legacy 3DES-MD5 where client compatibility permits
  3. Short Key Lifetimes: Reduce Phase 2 key lifetime to 3600 seconds (1 hour) for frequent rekeying
  4. User Account Policies: Implement password complexity requirements and account lockout thresholds
  5. Logging and Monitoring: Enable VPN event logging under Log & Report > Settings > VPN Events
  6. Client IP Pool Isolation: Place L2TP client address range in separate subnet with restrictive policies

Conclusion: Strategic Implementation Guidance

L2TP/IPsec on FortiGate delivers a standards-based remote access solution ideal for environments requiring native OS client compatibility without third-party software deployment. While configuration demands CLI expertise for L2TP parameters and careful attention to transport-mode requirements, the resulting infrastructure provides robust security through IPsec encryption combined with universal client accessibility.

Organizations should prioritize route-based configuration for new deployments due to superior administrative flexibility, while maintaining awareness of critical version-specific requirements—particularly the mandatory net-device enable setting for multi-client NAT scenarios and post-upgrade configuration adjustments required in FortiOS 7.0.1+.

For environments requiring stronger authentication, integrate RADIUS with MFA solutions like WatchGuard AuthPoint or Microsoft Azure MFA, while acknowledging protocol limitations with Azure AD-synced accounts requiring MS-CHAPv2. Always validate NAT traversal capabilities during design phase, as this remains the most frequent cause of deployment failures in cloud and multi-tenant environments.

Frequently Asked Questions (FAQ)

Can I configure L2TP entirely through the FortiGate GUI?

No. While IPsec phases and firewall policies can be configured via GUI (VPN > IPsec Wizard), L2TP-specific parameters (config vpn l2tp) require CLI access. The GUI lacks fields for client IP pool definition, user group assignment, and IPsec enforcement settings.

Why does my Windows client show "Error 789: The L2TP connection attempt failed"?

This typically indicates IPsec negotiation failure. Verify: (1) IPsec Policy Agent service is running with Automatic startup; (2) Pre-shared key matches exactly between client and FortiGate; (3) NAT-T is enabled on FortiGate Phase 1 when behind NAT; (4) Windows registry key ProhibitIpSec is set to 0.

What's the difference between policy-based and route-based L2TP/IPsec?

Policy-based binds the tunnel directly to security policies using proxy IDs, while route-based creates a virtual interface (l2t.root) that participates in standard routing. Route-based offers superior flexibility for complex topologies and is Fortinet's recommended approach for new deployments, though policy-based remains valid for simpler scenarios.

Can multiple users connect from behind the same NAT device?

Yes, but only with route-based configuration where set net-device enable is configured in Phase 1-interface. Without this setting, FortiGate cannot distinguish multiple L2TP sessions originating from the same public IP address.

Does FortiGate support L2TP without IPsec encryption?

Technically yes, but strongly discouraged. The enforce-ipsec-interface disable setting permits unencrypted L2TP, exposing credentials and data to interception. Always enable IPsec enforcement for production deployments.

How do I troubleshoot L2TP connections that authenticate but cannot access resources?

Verify three elements: (1) Firewall policy exists allowing traffic from L2TP client IP range to destination resources; (2) Client receives correct IP address from configured pool (check via diagnose vpn l2tp list); (3) Return traffic policies exist with NAT enabled if clients require internet access.

Are macOS and Linux clients fully supported?

Yes. FortiOS 4.0 MR3+ supports macOS connections with empty AVP host names. Linux clients using NetworkManager or strongSwan work reliably with standard L2TP/IPsec configuration. All platforms require identical pre-shared keys and user credentials.

What happens after upgrading to FortiOS 7.0.1+?

L2TP over IPsec configurations from 6.4.x/7.0.0 require manual updates post-upgrade. Review Fortinet Technical Tip "Manual upgradation of L2TP over IPsec configuration after upgrading from 6.4.x or 7.0..." for specific migration steps to prevent connectivity loss.

Can I use certificate authentication instead of pre-shared keys?

Yes. Phase 1 supports certificate authentication (set authmethod signature) with PKI user groups. However, Windows native L2TP clients have limited certificate support compared to pre-shared keys, potentially complicating deployment.

Why is transport mode required instead of tunnel mode?

L2TP already provides tunneling functionality at Layer 2. IPsec's role is encryption only, making transport mode appropriate. Tunnel mode would create unnecessary double encapsulation incompatible with Windows/macOS L2TP clients.