DNS and VPN Users

[seadave]

This issue has been discussed in may ways and referred to in post such as this:

https://forum.fortinet.com/tm.aspx?m=119883#183227

But I wanted to see if anyone has any remaining ideas.

To set the stage, in a proper Windows AD environment, DNS integrated with AD only allows secure updates from an authorized DHCP server that allocates IPs from one or more pools assigned to one or more subnets.  Authenticated clients can also have their NICs configured to register in DNS, but Microsoft suggests this isn't a good option:

https://support.microsoft.com/en-us/help/2933537/clearing-the-register-this-connection-s-addresses-i...

This requires a proper understanding of scope and DNS options such as lease time and scavenging.  I read a lot of posts by folks who don't understand how this works, such as setting the lease or scavenging time too low.  More info here:

https://blogs.msmvps.com/acefekay/2016/08/13/dynamic-dns-updates-how-to-get-it-to-work-with-dhcp-sca...

Our DNS and DHCP is setup following these Good Practices recommendations and we have no issues except for FortiClient endpoints.

Our problem is as follows.  We have right now ~150 users who connect via SSLVPN full tunnel.  They need full tunnel in to various services, but we also have some internal ops and security services that need name resolution to those clients from the inside to their temporarily leased VPN IP they happen to be using.

Because of some default settings in Windows, the following problems arise:

1. The option on Windows Networking for IPv4 DNS "Register this connection in DNS" on the Wifi or local NIC will register the clients remote LAN IP in Corporate DNS if enabled.  It is obviously undesirable to have a home LAN private IP in corporate DNS.

2. The client's Fortinet allocated VPN IP will also be registered.  This ends up creating two distinct records in DNS for each client.  Because the client is registering the record and it is not being handled by an authorized DHCP server, the record persists after the connection is dropped.  After a few days, DNS is filled with multiple A records of different hostnames pointing to the same 10.253.1.x addresses and unique 192.168 and 10.0 addresses, which also sometimes overlap.

3. Because NBT/NetBIOS has to be disabled on EVERY SINGLE interface we end up with lots of traffic related to clients trying to resolve each others name over port 137/NBT if that setting has been missed.  We have made multiple attempts to bulk set all interfaces to NetBIOS disabled but never seems to be entirely applied.  We are also using the DHCP option 001 to disable.

The above creates name resolution issues and pollutes our DNS with bogus records.  Host A records with multiple IPs and IPs associated with multiple hosts.  One solution would to prevent VPN clients from registering in AD DNS, but then we lose name resolution from internal services and HelpDesk.

Another option is to ensure the client's local wifi and Ethernet NICs are set to NOT "Register this connection in DNS".  That appears to fix problem #1 but is onerous to enforce.

To force the registration, Fortinet suggests:

https://kb.fortinet.com/k....do?externalID=FD36014

The ideal solution would be to have the Fortinet support ip-helper/DHCP Forwarding so that they authorized Windows DHCP server could allocate addresses.  Despite their being some old CLI (we are on 6.0.9 at the moment) that suggests this can be done, this article appears to indicate it isn't supported.

https://forum.fortinet.com/FindPost/159652

So has anyone else had to deal with this issue?  Were you militant about how you configured NBT and DNS setting on all your clients?  Did you find a way to allocate address other than using the FortiGate for DHCP?  Is that even possible?  I was considering perhaps enabling DNS on the FortiGate and allowing some sort of querying or zone publishing but not sure if that will gain me anything that additional complexity.

Appreciate any info or ideas that folks might have.

[FortiMike]

Hii All,

Has anyone found a solution or workaround this this problem yet?

Regards

[seadave]

We had to be very specific about how we configured NICs (including the pseudo ones created by Forticlient) on our laptops.  I think we use a script to ensure that is consistent.  It is unfortunate that Fortinet hasn't developed some sort of proxy/update that can push these changes to DNS when a client connects.  This of course works natively with IPSec (operating at Layer 3) but not SSLVPN (operating at layers 4-7).  To avoid DNS pollution, we made sure that we had scavenging setup properly (see my first post, this is critical and many people don't do this) and we also have a secondary script that looks for IP ranges that are from home LANs in the event those are published due to improper settings and it purges those from DNS periodically.  It is essential you use an odd 10. address for Fortinet DHCP to avoid conflicting with home LANs.  That is why they ship suggesting the 10.253.0.0/24 range.

[alfred0809]

The option on Windows Networking for IPv4 DNS "Register this connection in DNS" on the Wifi or local NIC will register the clients remote LAN IP in Corporate DNS if enabled.  It is obviously undesirable to have a home LAN private IP in corporate DNS.

[mmartins]

try this.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Able-to-see-both-local-IP-and-SSL-vpn-Ip-o...

[SteveTheGreat]

Broad. Integrated. Automated.