New Member

Question

Client DNS registering not working with split DNS.

Forum|Forum|2 years ago
February 16, 2024
11 replies
8886 views

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 !

FortiClient

AEK

SuperUser

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.

AEK

ArnaudLAuthor

New Member

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

SuperUser

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.

AEK

ArnaudLAuthor

New Member

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

SuperUser

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.

AEK

ArnaudLAuthor

New Member

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

Staff

Hi @ArnaudL,

Please refer to https://community.fortinet.com/t5/FortiClient/Technical-Tip-How-to-enable-workstation-DNS-registration-through/ta-p/196305

Regards,

ArnaudLAuthor

New Member

Hi @hbac

This did not help. I just connected this morning and my workstation's IP has not been updated in the internal DNS.

I still have the same error in the event log (8019). At least it's not happening twice per second but only once (I guess this might have been a windows bug).

BTW, why would this work if ipconfig /registerdns fails ? Does this registry key behaves differently than the "standard" registration ?

bluemerle

Visitor III

We used the FortiClient (EMS) and found that it breaks the Secure DynamicDNS Update process just by having the app installed on the PC.

FortiGate bug ID 0964456

Rel. https://community.fortinet.com/t5/Support-Forum/FortiClient-EMS-DNS-Dynamic-update-issue/m-p/279675

We currently use the free FortiClient VPN 7.2.2.0864, that does not habe the DNS issue.

You can test this by going to your DNS server, Zone properties, General Tab and permit unsecure "Dynamic updates".

Sign up

Login with SSO

Login to the community

Login with SSO