Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
fcb
Contributor

DHCP Relay for Multiple Dial-Up IPSEC Tunnels

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

4 REPLIES 4
pminarik
Staff
Staff

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)

[ corrections always welcome ]
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.

[ corrections always welcome ]
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!

 

 

Labels
Top Kudoed Authors