Client DNS registering not working with split DNS.

[ArnaudL]

Hi community !

We have setup split DNS on our SSLVPN for our remote workers that works quite well.
All there requests to internal names are forwarded to our internal DNS servers via the tunnel, all "normal" requests are using the users public DNS. Fine, that's how it is supposed to work.

The problem is that when the client tries to update its DNS record on the AD DNS server (ie ipconfig /registerdns), the registration packets are not routed correctly to our internal servers. They are sent to the public DNS servers which, of course, refuse the registration request.

There are two consequences.

First the AD DNS is not correctly updated so remote workstations cannot be joined via there FQDN. That's already pretty bad because some of our processes require the workstations to be reached from devices inside our LAN.

Second, the interface tries very hard to register the DNS entry, and our windows log is spammed with DNS registration errors (event ID 8019, twice per second). The DNS Client is using form 10% to 25% of CPU on these workstations ! 

We tried to not use split DNS and to route all requests through the tunnel to our internal server, but the tunnel is very often not fast enough (remote workers often have connections with quite high latency). Therefore the system becomes very painful to use.

Another precision : the windows DNS Client is trying to register its DNS record on its main network interface (Ethernet or Wifi), which is fine when working from the office but not when working remotely. It is not trying to register its DNS record on the "Fortinet SSL VPN Virtual Ethernet Adapter" !

Is there anything I can do about this, or is this something that should be fixed in Forticlient ?

Thanks !

[AEK]

Hi Arnaud

Try check the following:

• The internal corporate DNS server should be set as primary DNS server in SSL VPN settings, before the public DNS
• Then check in firewall traffic logs if any DNS registration related traffic is being blocked from VPN clients to internal DNS server

Hope this helps.

[ArnaudL]

Hi AEK, thanks for helping.

It is set as "same as client system dns", because we want public queries to go through the client system dns and private queries to go through the tunnel.

In the portal settings we have split dns with our internal servers definied for our own domains (i.e. FQDN of our AD domain), but then indeed the internal servers are 3rd and 4th in the list for the Fortinet SSL adapter.

If in SSL VPN settings I set my internal servers as primary, what will I define the public DNS servers to? I cannot guess, and maybe my remote workers ISP does not allow resolution through servers other than their own wo I cannot safely set them to Google our Cloudflare for instance.

What do you think ? 

[AEK]

Hi Arnaud

I guess you internal corp clients have internal corp DNS server set as their primary DNS server, right? I think that's the case for all companies, they even don't set any public DNS as secondary DNS server.

Well, for you SSL VPN clients it is like if they are inside, so they should have internal DNS server as primary, and if needed they can have public DNS or ISP DNS as secondary, even if you have split tunnel.

[ArnaudL]

They all are in DHCP, so when connected to our LAN indeed they only have our internal servers as primary and no other DNS.

When they are working from remote they have their ISP's DNS servers automatically configured by their internet box, and Fortinet adds our internals as 3 and 4.

So how I understand this (I am probably wrong, you tell me), is if I set the DNS manually in SSL VPN Settings, they will not have their ISP's DNS set on their interface and so no split DNS will take place. Is this wrong ?

[AEK]

If I'm not wrong and I don't know if it is the same for all OS, when you set internal DNS server as primary, once the VPN client connects it will set it as primary and it will set it's old primary (i.e.: ISP's) as secondary or 3rd. This is my guess, please double check.

Now even in case the VPN client once it connects drops his ISP DNS and set corp DNS as its unique DNS server (I suppose here that your corp DNS servers resolves public domains as well), the split tunnel remains working, only DNS traffic is not split. But this is not an issue since DNS traffic is about 1% of the whole traffic, so it will not consume your VPN bandwidth.

[ArnaudL]

---

@AEK wrote:

If I'm not wrong and I don't know if it is the same for all OS, when you set internal DNS server as primary, once the VPN client connects it will set it as primary and it will set it's old primary (i.e.: ISP's) as secondary or 3rd. This is my guess, please double check.

---

OK I checked. If I define the DNS servers, the old ones (ISP) are removed. If I set "use client DNS", the ISP ones are kept (of course), and the internal ones added as 3rd and 4th. Because of my split DNS config I guess.

The problem is that if I send ipconfig /registerdns, windows does not try to register on the 3rd and 4th servers. I have an error that registration failed dur to a security error (which is true on the public DNSes), but it does not try on all servers.

In my Fortinel SSL adapter settings, if I manually move my internal server to first position, ipconfig /registerdns does work. That's not what I want though, I want it to only resolve internal names and do dns registration because my workstations fqdn IS an internal name, so that's why I believe it should forward these packets.

[AEK]

Good, this clarifies a lot of things.

So if you need to keep pub DNS first, then you need to find something at OS level to send ipconfig /registerdns to the 2nd or 3rd or to a specific DNS server.

That brings you to the first post but with more clear situation.

[ArnaudL]

OK, so I checked with this configuration, but the problem as I mentioned in my first post is that all DNS traffic is going through the tunnel.
It is not a bandwidth problem, it is a latency problem. DNS queries takes tens of milliseconds when resolved over the tunnel, and less than 10ms when resolved directly over the internet.
For typical computer use, it makes a huge difference. This is how I was setup at first but I had to switch to split DNS precisely because all remote users were complaining that browsing the internet got terribly slow when VP was connected (and we DO have split tunneling so it was not a bandwidth problem but definitively a DNS latency problem).

Actually, my configuration with split DNS is working really good, the only problem is this DNS registration that is not routed by the Forticlient SSL adapter to my internal DNS. It does correctly route normal DNS queries though, so I guess it is a problem with Forticlient not intercepting these specific queries, right ?

[hbac]

Hi @ArnaudL,

Please refer to https://community.fortinet.com/t5/FortiClient/Technical-Tip-How-to-enable-workstation-DNS-registrati...

Regards,