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
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)
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
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.