Technical Tip: How to configure IPsec dialup VPN using IKEv2 with DHCP proxy and giaddr

[Anonymous]

Description

This article describes how to configure an IKEv2 IPsec dialup tunnel that serves dynamic addresses to clients using DHCP and IKE mode-config. This article notably uses the gateway IP address (giaddr) setting on the FortiGate to inform the DHCP server as to which specific DHCP subnet/pool should be used, which was first added in FortiOS 6.4: Support defining gateway IP addresses in IPsec with mode-config and DHCP.

Scope

FortiGate, IPsec

Solution

FortiGate Configuration

Use the following steps to configure the setup described above:

1. Enable the dhcp-proxy function under config system settings and specify the target DHCP server:
   • Optionally, use the dhcp-proxy-interface-select-method option to specify the FortiGate interface used to reach the DHCP server (see also: Technical Tip: Traffic routing from SD-WAN member in case tunnel interface does not have an IP addre...).
   • The DHCP Proxy function is used by the FortiGate to receive dynamic address requests from dialup VPN clients and proxy them as DHCP requests to a DHCP server (as opposed to the client sending DHCP directly).
   • Ensure that the FortiGate has a network route to the DHCP server if it is not on a directly-connected subnet.

config system settings

set dhcp-proxy enable
set dhcp-server-ip '10.220.0.107'

set dhcp-proxy-interface-select-method [ auto | sdwan | specify ]

set dhcp-proxy-interface <interface_name, if using specify option>

end

2. Create a User Group that is allowed to authenticate to the IKEv2 VPN:

show user group

edit 'vpn-usergroup'

set member 'vpn-user'

next

end

3. Configure the IKEv2 IPsec tunnel (phase 1 and phase 2):
   • Note: The configuration in this article uses a single User Group placed directly into the IPsec phase 1 settings, which means that only that single user group can associate with this VPN tunnel. To allow multiple user groups to share the VPN tunnel instead (i.e., one VPN tunnel with role-based access based on Firewall Policies), check out the following documents:
     • Technical Tip: How to use multiple groups with EAP for IKEv2 (SAML/RADIUS/local)
     • Using single or multiple user groups for user authentication
   • In this example, the DHCP giaddr is set to 10.220.0.1 to instruct the DHCP server to assign an address from the address pool of 10.220.0.0/24.

config vpn ipsec phase1-interface

edit 'VPN-v2'

set type dynamic
set interface 'port1'
set ike-version 2
set peertype any
set net-device disable
set mode-cfg enable <--- Mandatory to allow VPN server (FortiGate) to provide dynamic addressing/configuration to VPN client.
set proposal aes128-sha256 aes256-sha256 aes128gcm-prfsha256 aes256gcm-prfsha384 chacha20poly1305-prfsha256
set dhgrp 20
set eap enable <--- IKEv2 specific, mandatory to support VPN client authentication.
set eap-identity send-request <--- IKEv2 specific, mandatory to support VPN client authentication.
set authusrgrp 'vpn-usergroup' <--- Optional, used if only a single user group is required to authenticate to the IKEv2 VPN tunnel (see note above).
set assign-ip enable <--- Enabled by default, enables dynamic IP address assignment to VPN clients.
set assign-ip-from dhcp <--- Mandatory for assigning IP via DHCP, rather than from a local IP range.
set dhcp-ra-giaddr 10.220.0.1 <--- Gateway IP address (giaddr) used to indicate to the DHCP server as to which DHCP subnet should be served to the client.
set dns-mode auto
set ipv4-split-include 'VPN-v2_split'
set save-password enable
set psksecret <pre-shared_key>

next

end

config vpn ipsec phase2-interface

edit 'VPN-v2'

set phase1name 'VPN-v2'
set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305

next

end

4. Create Firewall Policies to allow VPN users to access the internal subnet:
   • Note how User Groups are not added to the Firewall Policy when they have been set in the VPN phase 1 configuration instead.

config firewall policy

edit 1

set name 'vpn_VPN-v2_remote_0'
set srcintf 'VPN-v2'
set dstintf 'internal'
set srcaddr 'all'
set dstaddr 'VPN-v2_split'
set action accept
set schedule 'always'
set service 'ALL'
set nat enable <--- Source NAT is not mandatory if downstream devices have routes to reach the VPN client subnet.

next

end

FortiClient Configuration

The configuration on FortiClient must generally match the IPsec phase 1 and phase 2 settings on the FortiGate. Key points to remember are as follows:

• The FortiClient IKE Proposal only needs to match at least one Encryption/Authentication pair on the FortiGate, but it does not need to include all of them.
• Similarly, the DH Group setting only needs to match one of the available options on the FortiGate. Due to FortiClient limitations, it is recommended to only select a single DH Group on the FortiClient side from the list configured on the FortiGate (i.e., if DH Groups 20, 14, and 5 are set on the FortiGate, only select 20 on FortiClient).
• Only select Mode Config for Options/Address Assignment, not DHCP over IPsec (legacy option, only used for DHCP relay with IKEv1).

Verification

The following debug snippets are taken from the output of diagnose debug app ike -1 and diagnose debug enable:

ike 0:9f67930076a4be90/0000000000000000:29:         type=DH_GROUP, val=ECP384.
ike 0:9f67930076a4be90/0000000000000000:29: lifetime=86400
ike 0:9f67930076a4be90/0000000000000000:29: SA proposal chosen, matched gateway VPN-v2
ike 0:VPN-v2: created connection: 0xdad9c10 3 10.109.21.41->10.109.20.72:500.
...
ike 0:VPN-v2:29: send EAP message to FNBAM
ike 0:VPN-v2: EAP 709192309 pending
ike 0:VPN-v2:29 EAP 709192309 result 0
ike 0:VPN-v2: EAP succeeded for user "vpn-user" group "vpn-usergroup" 2FA=no
ike 0:VPN-v2:29: responder preparing EAP pass through message
ike 0:VPN-v2:29: enc 00000008031F00040706050403020107
ike 0:VPN-v2:29: out 9F67930076A4BE90238A05BA09963DD42E202320000000040000005030000034CC263336D17DFE233E0A911999A526E491702666F67AC46FE7141F0D69BB9B1B1F471A98303C89A95EC7BC1DFD03CBF4
ike 0:VPN-v2:29: sent IKE msg (AUTH_RESPONSE): 10.109.21.41:500->10.109.20.72:500, len=80, vrf=0, id=9f67930076a4be90/238a05ba09963dd4:00000004
ike 0: comes 10.109.20.72:500->10.109.21.41:500,ifindex=3,vrf=0....
ike 0: IKEv2 exchange=AUTH id=9f67930076a4be90/238a05ba09963dd4:00000005 len=112
ike 0: in 9F67930076A4BE90238A05BA09963DD42E2023080000000500000070270000549C9158580F47E9BA156CDFF346807A23F1F367E52035FE7C9CE1867607EFC5C5F66BC4FBC2E1E97E4A79EEC8EBB38010858E0EF2160F64552E8F2BD47DEEF2F13ADAEA5EB6AA4E3BA19B0B14B271CDE2
ike 0:VPN-v2:29: dec 9F67930076A4BE90238A05BA09963DD42E2023080000000500000048270000040000002802000000B35F86693CACBE23BAFE13DBC7DF0E94BA01B37846F2FB84AE8F70C7EB57A820
ike 0:VPN-v2:29: responder received AUTH msg
ike 0:VPN-v2:29: auth verify done
ike 0:VPN-v2:29: responder AUTH continuation
ike 0:VPN-v2:29: authentication succeeded
ike 0:VPN-v2:29: responder creating new child
ike 0:VPN-v2:29: mode-cfg type 7 request 16:'46435438303033313936343233343539'
ike 0:VPN-v2:29: mode-cfg received APPLICATION_VERSION 'FCT8003196423459'
ike 0:VPN-v2:29: mode-cfg type 1 request 0:''
ike 0:VPN-v2:29: IPv4 address requested, using DHCP
ike 0:VPN-v2:29: sending DHCP request
ike 0:39 response IP '10.220.0.128/255.255.255.0'
ike 0:VPN-v2:29: DHCP assigned address 10.220.0.128/255.255.255.0
ike 0:VPN-v2:29: DNS 10.220.0.107

Additional Notes:

In IKEv1 the DHCP traffic is sourced by the client and relayed by the FortiGate with a configured DHCP relay interface. See also: IPsec VPN with external DHCP service.

However, in IKEv2 DHCP is handled by the FortiGate (acting as a proxy on behalf of the VPN client), and the FortiGate then assigns this DHCP address via mode-config to the VPN client.

Notably, the source of these DHCP requests (from the DHCP server's perspective) will always appear to be the FortiGate's MAC address, and so the FortiGate will append Option 61 (Client Identifier) when transmitting to the DHCP server. This option is based on the client's supplied username, and it is used by the DHCP server to identify and manage DHCP leases.

Because of this, it is expected behavior that when a client connects to the VPN tunnel using the same username but two different devices, both devices will receive the same IP address from DHCP (since the Client Identifier is the same). This will be visible in packet captures of the DHCP exchange between the FortiGate and the DHCP server, specifically the DHCP Discover message.

Related articles:

Technical Tip: Configuring DHCP relay over IPSec VPN with overlapping subnets

Defining gateway IP addresses in IPsec with mode-config and DHCP

Technical Tip: IPsec IKEv2 with mode-config and DHCP using the gateway IP address