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.

[VocalityTech]

I'm having the same problem with my remote workers.  It's disheartening to see this is an issue that has existed for 5 years.

[bamather]

I am dealing with the same kind of issue did you figure anything out with this?

[seadave · Accepted solution]

Kind of sort of.  Our Fortinet vendor related the following:

One item that we have found in EMS that is helpful with this is relating to the DNS Cache Service control on the endpoints connecting via VPN. ... has played with this a bit and I think we determined that restarting the dnscache services has the best results since restarting that service upon VPN connection sends the updated IP to the DNS server to update its records.

We have yet to confirm if this is the preferred solution.

[seadave]

The real solution to this I think is having the Fortinet proxy a DHCP request and ack between the firewall and Windows/Linux DHCP server (similar to a "dhcp helper" command in most switches).  That would keep things consistent, regardless of client settings.  Maybe not possible due to how SSL VPN works.  Lots of factors at play and endpoint settings that can cause conflict.

[seadave]

The real solution to this I think is having the Fortinet proxy a DHCP request and ack between the firewall and Windows/Linux DHCP server (similar to a "dhcp helper" command in most switches).  That would keep things consistent, regardless of client settings.  Maybe not possible due to how SSL VPN works.  Lots of factors at play and endpoint settings that can cause conflict.

[bamather]

I agree a DHCP relay would be very helpful.  I found that fortigates do have this function with and IPsec VPN but not SSL.  I don't think it is a limitation as cisco anyconnect can do DHCP relay via SSL vpn.  

[dhanushx012]

I'm a bit confused, As far as I know most people get a static IP from their ISP's right? They don't generally change do they? I don't see why DynDNS would be needed. Also I don't see why my clients would need DNS setup like google DNS, Once the connection is established to my home network I would assume that the clients would use the DNS configured on the home network. Am I missing something? get-mxplayer.in mxplayer

[bamather]

There are 2 styles of VPNs. There is Site-to-Site VPN.  This is used when you have 2 devices (like to fortigates) that set on the edge of the network with a static IP from the ISP.  This will connect the 2 office together and make clients/servers routable between the 2 locations.  In this case usually both offices have different network with different subnets.  In the DHCP server you create a scope with per office with a range of IPs that can be handed out.  Most of the time you use a shared DNS/DHCP server that clients register to in both offices so you can find the clients by name resolution.  Since you are using the same server for DNS/DHCP when a new client connects it will get an ip that is not being used so there can be no overlapping.  

Then there is Point-to-Site VPN.  This is used when a user is at home and need access to corporate resources. This is what I am having problems with.   When a client connects to the VPN from their home the fortigate assigns them a IP in a certain range kind of like DHCP.  This range used for firewall and routing rules.  Not sure if there is or why you would want to make the client static IPs.  Once the computer connects it is now on the corporate network and registered its DNS to my windows DNS server.  This is so all the servers/computer in the corporate network can talk to it using the name instead of IP.  If I allowed the clients to only use googles DNS it would not now how to get to my servers via name.  So for these reason we point it at our DNS server so it can reach all our internal servers/clients by name instead of IP.  

The problem I am having is the fortigate (My DHCP server) and my DNS (Windows Server) do not talk to each other.  So the fortigate hands out an 10.0.0.1 to a client and that client register its DNS to my windows server.  The the client disconnects which removed that IP from the fortigate to be used again, but my windows DNS server still has it pointing to the clients name.  A new client now connects and gets 10.0.0.1 and registers to my windows DNS.  The windows server saves it and now I have 2 clients with different names, but they have same IP in my DNS server.  This means when a internal server wants to reach that client by name it can't or it has a 50/50 chance.  If disconnects happen alot through out the day, you can have many client registrations with the same IP address causing name resolution to not work.  

What Fortigates should do is relay the DHCP request to my internal DHCP/DNS server.  It would work like the site-to-site and would fix the issue.  This is how most vendors do their Point-to-Site VPN connections and I'm not sure why fortinet doesn't.  If you use a IPsec Point-to-Site VPN then you can, but doesn't have the option for SSL VPN.  

[WagoL]

dfollis wrote:

Kind of sort of.  Our Fortinet vendor related the following:

One item that we have found in EMS that is helpful with this is relating to the DNS Cache Service control on the endpoints connecting via VPN. ... has played with this a bit and I think we determined that restarting the dnscache services has the best results since restarting that service upon VPN connection sends the updated IP to the DNS server to update its records.

We have yet to confirm if this is the preferred solution.

Using this settings in EMS the IP that is getting registered in DNS is not the IP of the SSLVPN interface.

But my own private IP of my wifi/cable connection.