DHCP Relay for Multiple Dial-Up IPSEC Tunnels

[fcb]

Internal Interface of Fortigate: 10.10.10.10

Dial-Up Clients network: 10.20.20.20 - 100 Gateway: 10.20.20.5

DHCP Server: 10.10.1.7

I've got three different IPSEC VPN's published off of a single 500 series gate but because our AD DNS isn't registering the machines properly, I want to move this to so that the dial-up clients are getting their addy's from a member dhcp server... I've even got the 2FA working on these but when the dhcp request hits the server, it's using the LAN interface of the gate so dhcp is trying to assign addresses based off of the internal interface on the gate and not the network that the dial-up clients will be using. In the dhcp request I can see this happening:

corp500gw: diag app dhcp-relay
dhcprelay: checking if we need to reconfigure
dhcprelay: no changes detected
Proccessing RTM_NEWLINK event.
Relay client interface: vpn.segra2_0
netlink message!
Proccessing RTM_NEWLINK event.
Proccessing RTM_NEWLINK event.
dhcprelay: checking if we need to reconfigure
dhcprelay: no changes detected
proxy request vfid=0 type=0 id=29 client_id=64:77:74:75:67:67:6c:65
Add proxy request type=0 id=29 client_id=64:77:74:75:67:67:6c:65
make discover
make dhcp message, code=1
Insert option(53), len(1)
Insert max message len (1458)
Insert option(57), len(2)
Insert client ID
Insert option(61), len(8)
Insert requested options
Insert option(55), len(9)
Insert class ID option
Insert option(60), len(13)
Insert option(82), len(6)
found route to 10.10.1.7 via 10.10.10.10 iif=0 oif=19/port1, mode=auto, ifname=
(xid:3488b913) forwarding dhcp request from 10.10.10.10:67 to 10.10.1.7:67 (should be 10.20.20.20.5)
proxy request vfid=0 type=0 id=29 client_id=64:77:74:75:67:67:6c:65
Remove proxy request type=0 id=29 client_id=64:77:74:75:67:67:6c:65
Add proxy request type=0 id=29 client_id=64:77:74:75:67:67:6c:65
make discover
make dhcp message, code=1
Insert option(53), len(1)
Insert max message len (1458)
Insert option(57), len(2)
Insert client ID
Insert option(61), len(8)
Insert requested options
Insert option(55), len(9)
Insert class ID option
Insert option(60), len(13)

I know this to be the issue because if I create a scope on the DHCP server for 10.10.10.10 I get an IP when attempting the connection... Otherwise (when trying to use the 10.20.20.5) I see the packets hit the DHCP server but since they are looking for a non-present scope for router ID: 10.10.10.10, nothing happens.

I can't seem to locate how to tell the gate to send the request as the network associated with the VPN and not the Internal Interface of the gate

[pminarik]

Can you share an outline of your current configuration?

Are you doing "pure" DHCP (the connecting client is sending out DHCP requests), or are you doing DHCP through mode config? (connecting client receives an IP through mode-config, but the FortiGate decides the IP to be assigned by requesting it from the DHCP server)

[fcb]

We're trying to solve the problem of where our connected VPN devices are not updating their DNS sufficiently enough with the rest of the domain and in some cases not updating them at all. So a machine will be OnNet and have the local IP but when they go OffNet and connect to the VPN, they still show as having the local IP.  We decided that if they registered with our DHCP server that they would in turn register correctly in DNS. That and plus some other accounting that we'd get with them actually getting an IP address from the "domain joined" DHCP servers.

I thought with the config I was using that they (the clients) would talk directly to the DHCP server (and that's what I'm seeing if my scope is for 10.10.10.0 network) so my thoughts are that there has to be some to have the Fortigate specify what network the DHCP Requests are for.

config vpn ipsec p1
edit "vpn.ISP2"
set type dynamic
set interface "port4"
set mode aggressive
set peertype one
set net-device enable
set mode-cfg enable
set proposal aes256-sha512 aes256-sha384
set comments "RA3"
set dhgrp 5
set xauthtype auto

set authusrgrp "radius.fac.users.vpn"
set peerid "IP2"
set assign-ip-from dhcp
set save-password enable

config system interface isp2

name : vpn.segra2
vdom : root
vrf : 0
cli-conn-status : 0
client-options:
distance : 5
priority : 0
dhcp-relay-interface-select-method: auto
dhcp-relay-service : enable
ip : 10.20.20.5 255.255.255.255
allowaccess : ping
arpforward : enable
broadcast-forward : disable
bfd : global
icmp-send-redirect : enable

edgwfw (vpn.sisp2) # get
name : vpn.isp22
phase1name : vpn.isp22
proposal : aes256-sha512 aes256-sha384
pfs : enable
ipv4-df : disable
dhgrp : 5
replay : enable
keepalive : enable
add-route : phase1
auto-discovery-sender: phase1
auto-discovery-forwarder: phase1
keylife-type : seconds
single-source : disable
route-overlap : use-new
encapsulation : tunnel-mode
comments : VPN: vpn.isp22 (Created by VPN wizard)
diffserv : disable
protocol : 0
src-addr-type : subnet
src-port : 0
dst-addr-type : subnet
dst-port : 0
keylifeseconds : 43200
src-subnet : 0.0.0.0 0.0.0.0
dst-subnet : 0.0.0.0 0.0.0.0

[pminarik]

Thanks for the clarification. So we can see you're doing mode-config + DHCP:

...
set mode-cfg enable
...
set assign-ip-from dhcp
...

Have you had a look at this KB article yet? https://community.fortinet.com/t5/FortiGate/Technical-Tip-IPsec-IKEv2-with-mode-config-and-DHCP-usin...

Perhaps you'll be able to find some config detail that you missed. I suspect `set dhcp-ra-giaddr` probably needs to be added in phase1.

[fcb]

That exact KB article had in fact eluded me.... under the IPSEC P1 I was missing:  set dhcp-ra-giaddr 10.20.20.5

Thanks so much! I'm fixed just like that! Thanks to  @pminarik - Nice find on that article! Google could not take most of those search terms and pull that one out of the hat.

Thanks again!

[BigLilFella]

Did this actually solve your problem with DNS though? In my experience when mode-config is set to do dhcp-relay, the firewall creates the request rather than the client. The request the firewall sends to the DHCP server does not include Option 12 - Hostname, so the DHCP server has no names associated with any of the leases it hands out, and therefore can't be relied upon to update DNS.

[dwtuggle]

I am the original poster of that thread but with the new login scheme I can't seem to login as that old "fcb" account but to answer your question, it did fix my problem. I am not entirely familiar with option 12 that you mention (appears to mainly be related to Cisco?) but I can tell you this: My use case was for these two or three IPSEC clients to use the AD DHCP server so that they could get a specific IP as a reservation so they could then be policy routed to a particular Interface on the firewall. As I recall, these clients did register their hostnames with the AD DNS server and everything worked as expected, but to be fair, my main goal was to hand each of them a specific IP which the Fortigate could not do. I can for sure confirm that they were able to use name resolution off of the AD DNS and will confirm that they registered their hostname(s) correctly if that's exactly what you're looking for so let me know and I can confirm that for you. I am 95% sure that they did though since we use EMS and Solarwinds which both require name resolution of the clients for our environment...

If that's not what you're looking for exactly, please elaborate a little and I'll be happy to help, if I can.

[BigLilFella]

Thanks for such a prompt response, I didn't have a lot of hope replying to a 2 year old message haha. Unfortunately I think our goals are a bit different...

Option 12 is just a way for the client to embed it's hostname in the DHCP request and isn't vendor specific. It's included in the requests the firewall relays from clients on our other network segments, but these requests are being created by the client and then forwarded by the firewall ("pure dhcp" as the commentor above called it). When using dhcp relay as part of mode-config for VPN clients, Option 12 is not included in the request the firewall is creating. As a result if I look at the DHCP leases on my Windows server, the Name field is blank for every lease. In your case since you are doing reservations exclusively, the Name field is being populated with what you set as the Reservation Name. I suspect though if you handed out a lease without using a reservation you would also see a blank name.

If I do figure out how to get the hostnames to come over, the plan is to then use DHCP to update DNS rather than having the clients do the registration. Our goal is to get rid of the stale addresses left over from after a tunnel disconnects but before scavenging can clean them up. 

[pminarik]

I don't even think the client's hostname is included in mode-config, so this may not even be possible purely with mode-config. (at the very least it is not listed here: https://datatracker.ietf.org/doc/html/draft-dukes-ike-mode-cfg-02#section-3.4 )

FortiClient does include it in a vendor-proprietary "FORTICLIENT_CONNECT" notification, but I am 1) not sure if the mode-cfg->DHCP configuration takes that into account, and 2) this wouldn't be helpful for 3rd party clients that don't advertise this FORTICLIENT_CONNECT message.

[BigLilFella1]

That's a great link, I'd agree then that there likely isn't a way we're going to get the hostnames to the DHCP server using mode-cfg. I do see that for my other network segments, where I'm using DHCP relay configured on the interface, the client does create the request with option 12 defined, and the firewall forwards all that info along when it relays the request. I'm wondering then if it's possible to configure the tunnel without mode-config and have it use DHCP relay configured on the tunnel interface?