Complete Guide: FortiGate DHCP over IPsec VPN in FortiClient

Introduction to FortiGate DHCP over IPsec VPN

When enterprise network engineers deploy FortiGate Remote Access VPNs (Dial-Up IPsec), the default and most heavily documented method for assigning IP addresses to remote clients is Mode Config. Mode Config is highly automated—it pushes virtual IP addresses, DNS server settings, and split-tunneling routes down to the FortiClient seamlessly.

However, modern enterprise topologies frequently encounter scenarios where Mode Config is insufficient, and engineers must rely on a more traditional standard: DHCP over IPsec.

In this architecture, we strip away the automation. We disable Mode Config entirely and configure a literal DHCP server on the FortiGate’s virtual IPsec tunnel interface. The FortiClient initiates the tunnel, and once Phase 2 is established, it broadcasts standard DHCP Discover messages (UDP ports 67/68) directly through the encrypted payload to obtain its networking parameters.

In this comprehensive tutorial, we will walk through exactly how to configure DHCP over IPsec on a FortiOS device, the specific (and often hidden) CLI commands required to make it work, and how to configure the FortiClient endpoint to match.

1. Why Choose DHCP over IPsec?

Before diving into the configuration, it is important to understand why a NetOps team would choose this method over the standard Mode Config:

• Centralized IP Address Management (IPAM): DHCP over IPsec allows for seamless integration with central DHCP relay agents. If your organization mandates that a dedicated Windows Server or Linux DHCP daemon handles all IP allocations for auditing purposes, DHCP over IPsec allows you to relay those requests.
• Strict Compliance & Legacy Integration: Some legacy applications or strict zero-trust environments require standard DHCP lease negotiation (DORA) rather than firewall-pushed virtual IPs.
• Granular Control & Reservations: It allows administrators to utilize standard DHCP MAC-address reservations for specific VIP remote users.

2. Phase 1 & Phase 2 Cryptographic Deep Dive

Configuring the cryptographic tunnel for DHCP over IPsec requires meticulous attention to the settings. We must build a Dial-Up VPN while deliberately disabling the automation features that standard FortiClient IPsec tunnels rely on.

Step 2.1: Phase 1 Configuration (The IKE Gateway)

The Phase 1 configuration establishes the initial secure channel (IKE SA) between the FortiClient and the FortiGate.

Via the FortiOS GUI:

1. Navigate to VPN > IPsec Tunnels and click Create New > IPsec Tunnel.
2. Name the tunnel (e.g., Remote_Access_DHCP) and select the Custom template. Click Next.
3. Network Section:
   • IP Version: IPv4
   • Remote Gateway: Select Dialup User (Tells FortiOS to expect connections from unknown, dynamic public IPs).
   • Interface: Select your public-facing interface (e.g., wan1).
   • NAT Traversal: Enable (Crucial, as remote workers are almost always behind a home router).
4. Authentication Section:
   • Method: Pre-shared Key
   • Pre-shared Key: Enter a strong PSK.
   • Mode: Aggressive (Aggressive mode is highly recommended for dial-up VPNs).
   • Peer Options: Select Accept any peer ID.
5. Phase 1 Proposal Section:
   • Encryption: AES256 | Authentication: SHA256
   • Diffie-Hellman Group: 14
6. XAuth / Mode Config Section (CRITICAL STEP):
   • Mode Config: UNCHECK THIS BOX. This disables the FortiGate from automatically pushing virtual IPs. This is the defining step of a DHCP over IPsec deployment.

Via the FortiOS CLI (Phase 1 Equivalent):

config vpn ipsec phase1-interface
    edit "Remote_Access_DHCP"
        set type dynamic
        set interface "wan1"
        set ike-version 1
        set mode aggressive
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set dpd on-demand
        set dhgrp 14
        set psksecret "YourSecureKey123!"
        set mode-cfg disable    # CRITICAL: Disables automatic IP assignment
    next
end

Step 2.2: Phase 2 Configuration (The IPsec SA)

Phase 2 dictates the actual encryption of the payload data and defines the “Interesting Traffic” that is allowed to traverse the tunnel.

Via the FortiOS GUI:

1. Under the Phase 2 Selectors section, click the pencil icon to Edit the default selector.

2. Name: Remote_Access_DHCP_Ph2

3. Local Address: 0.0.0.0 / 0.0.0.0

4. Remote Address: 0.0.0.0 / 0.0.0.0

   (Setting both to 0.0.0.0/0 acts as a wildcard, allowing the tunnel to pass any traffic dynamically based on the client’s routing table).

5. Expand Advanced:

   • Encryption: AES256 | Authentication: SHA256

   • Perfect Forward Secrecy (PFS): Disable (Common for dial-up users to speed up re-keying).

config vpn ipsec phase2-interface
edit "Remote_Access_DHCP_Ph2"
set phase1name "Remote_Access_DHCP"
set proposal aes256-sha256
set pfs disable
set replay enable
set keepalive enable
# CRITICAL COMMAND: Allows DHCP broadcasts through the IPsec tunnel
set dhcp-ipsec enable 
next
end

3. Creating the Transit Firewall Policy

Even though the tunnel is built, traffic cannot enter your LAN without an explicit IPv4 policy.

1. Go to Policy & Objects > Firewall Policy > Create New.

2. Name: VPN_to_Internal

3. Incoming Interface: Remote_Access_DHCP (Your newly created IPsec tunnel)

4. Outgoing Interface: LAN (or internal)

5. Source: all

6. Destination: all (or your specific internal subnets)

7. Schedule: always

8. Service: ALL

9. Action: ACCEPT

10. NAT: Disabled (unless your internal core switch lacks a return static route back to the VPN subnet).

config firewall policy
edit 0
set name "VPN_to_Internal"
set srcintf "Remote_Access_DHCP"  # The name of your IPsec Phase 1 interface
set dstintf "internal"            # Replace with your actual LAN interface name (e.g., port2, LAN)
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set logtraffic all                 # Highly recommended for VPN troubleshooting
set nat disable                    # Standard practice: keep original client IP intact
next
end

4. Tunnel Interface & DHCP Server Setup (The Subnet Mask Trick)

Here is where standard VPN configurations fail. To use DHCP over IPsec, the virtual tunnel interface must have its own IP address and a DHCP server directly attached to it.

1. Go to Network > Interfaces.

2. Expand your physical WAN interface and click on your IPsec tunnel (Remote_Access_DHCP) to edit it.

3. IP/Network Mask (CRITICAL): Assign an IP address to the firewall’s side of the tunnel. For example: 10.10.10.1 / 255.255.255.255.

   Note: FortiOS strictly requires a /32 (255.255.255.255) subnet mask on the local interface for dial-up tunnels. Attempting to use a standard /24 will throw an “invalid netmask” GUI error.

4. Remote IP/Network Mask: 10.10.10.254 / 24 (This defines the scope of the remote network).

5. DHCP Server: Toggle this to Enabled.

   • Address Range: 10.10.10.11 to 10.10.10.20

   • Netmask: 255.255.255.0

5. The Secret Sauce: DHCP Server Type & Phase 2 CLI commands

If you stop at Step 4, your DHCP server will act like a standard LAN DHCP server. It will completely ignore DHCP Discover requests coming out of an encrypted IPsec tunnel. We must apply two specific configurations to fix this.

Step 5.1: Change the DHCP Server Type

1. In the interface DHCP server settings, expand Advanced.

2. Look for the Type setting and change it from Regular to IPsec.

(If this is hidden in your GUI version, configure it via CLI):

config system dhcp server
    edit 1  # Use 'show' to find the ID of the DHCP server you just created
        set server-type ipsec
    next
end

Step 5.2: Enable DHCP Broadcasts in Phase 2 (CLI ONLY)

There is one final configuration that does not exist in the FortiOS GUI. You must explicitly instruct the Phase 2 IPsec daemon to permit UDP Port 67 and 68 broadcast packets to traverse the encrypted tunnel.

Open the FortiOS CLI and execute the following:

config vpn ipsec phase2-interface
    edit "Remote_Access_DHCP_Ph2"
        set dhcp-ipsec enable    # THE CRITICAL COMMAND
    next
end

Without this command, the FortiGate drops the DHCP Discover packets immediately, and the client receives a broken 169.254.x.x IP address.

6. FortiClient Configuration & Manual Split Tunneling

Now that the firewall is fully configured, we must align the endpoint.

1. Open FortiClient and create a new IPsec VPN connection.

2. Remote Gateway: Enter your FortiGate’s public WAN IP.

3. Authentication: Pre-shared Key (YourSecureKey123!).

4. Phase 1: IKE Version 1, Aggressive Mode.

5. Phase 2: Advanced settings must match your FortiGate proposals (AES256/SHA256).

6. Mode Config: Uncheck this option.

7. DHCP over IPsec: Check this option.

Handling Split Tunneling Manually

A major architectural difference between Mode Config and DHCP over IPsec is how routing is handled. With Mode Config, the FortiGate dynamically pushes the “Interesting Traffic” routing table to the FortiClient.

With DHCP over IPsec, the firewall pushes zero routes. To prevent sending all of the user’s home internet traffic through the corporate VPN (Full Tunnel):

1. In FortiClient, check Enable Split Tunneling.

2. You must manually assign the destination network addresses (e.g., 14.140.42.0/24 or 192.168.100.0/24) directly inside the FortiClient UI. Only traffic destined for these explicitly defined networks will be routed into the IPsec tunnel.

7. Verification and Troubleshooting

Once connected, your FortiClient adapter should negotiate Phase 1, Phase 2, and then pause briefly while DORA (Discover, Offer, Request, Acknowledge) takes place.

Verification Checklist:

• Open Command Prompt on Windows and run ipconfig /all. Look for the Fortinet Virtual Adapter. It should have an IP from your DHCP pool (e.g., 10.10.10.11).

• Check your routing table (route print). You should see the manual split tunnel routes injected by FortiClient pointing to the virtual adapter.

• Ping a device on the internal network to verify end-to-end payload decryption.

Troubleshooting: Stuck on APIPA (169.254.x.x)

If FortiClient shows a successful connection (“Connected”) but your network adapter receives an IP address starting with 169.254.x.x, the DHCP negotiation has failed.

To debug this, run a packet capture on the FortiGate specifically for DHCP traffic:

diagnose sniffer packet any 'udp port 67 or udp port 68' 4 0 l

If you see DHCP Discover packets arriving from the client but no Offers being sent back from the FortiGate, you have missed the secret sauce. Verify immediately:

1. Did you change the DHCP Server Type from Regular to IPsec?

2. Did you enable set dhcp-ipsec enable inside the Phase 2 CLI configuration?

Conclusion

Transitioning from automated Mode Config to native DHCP over IPsec gives enterprise network engineers tighter control over IP address management, prevents routing conflicts, and allows for integration with dedicated external DHCP infrastructure. While it requires knowledge of hidden CLI commands and a manual approach to endpoint split tunneling, mastering this configuration ensures you can accommodate any remote-access edge case your organization requires.

Have you encountered any stubborn APIPA issues when deploying this in your environment? Drop a comment below or join the discussion in our NetOps community forum!

Read More : FortiGate IPsec Remote Access VPN Setup Guide