Problem with SSL VPN and DNS

VPN
1

EDIT: Solved! Disabling IPv6 as suggested by Slushmania and Craptcha fixed the issue. Thanks, guys!

Recently, my company migrated to a FortiGate firewall and use the newest FortiClient VPN to allow our users to connect. For the majority of users this works without a hitch. A few users, however, can sometimes not resolve hostnames. This seems to happen every 10 minutes or so. It’s a FortiGate 60F on v6.4.4 build 1803 (GA). Users use the newest FortiClient version. Split DNS and Split Tunneling is active.

Our company network is 192.168.0.0/23. This is not ideal but cannot be changed. First, we had issues with users who were in the 192.168.1.0/24 network at home due to route specificity. This was handled by creating /25 (i.e. 192.168.1.0/25, 192.168.1.128/25, …) networks so that the routes of the VPN have a higher specificity, thus capturing all 192.168.1.x requests. After setting a DNS suffix through the CLI everything works as intended for all but 2 users.

These two users are often not able to resolve hostnames. The VPN correctly sets the DNS on all of their connections and I can see the DNS requests in the firewall log. However, when contrasted with my own logs, I often see “Accept: IP connection error” on these requests. I’ve tried to use the CLI sniffer utility, but there, I only see 4 requests TO the firewall, and 2 requests back. This seems normal to me.

Additionally, whilst ping does not work and connecting via RDP and such fails nslookup returns the hostnames just fine, and a few seconds afterwards pinging the hostname will work.

Other than that I don’t see any irregularities. Do you perhaps have an idea on what I could try / examine next or what I could do to solve this?

EDIT: Some more tracing and wiresharking reveals the following (on the Firewall):

xxx.xx.xx.1 (client) → xxx.xxx.x.100 (dns): icmp: xxx.xx.xx.1 (client) udp port 55671 unreachable

On the local client I see in wireshark under “Internet Control Message Protocol” the following:

Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)

Checksum is correct and good, though. So, it’s with some likelihood a clientside problem… I just have no idea what.

2

In SSL VPN cases where:

  • Clients connected to the SSL VPN are sometimes unable to resolve internal DNS queries.
  • Communication via IPv4 address still works without issue.
  • The issue appears to be intermittent in nature.
  • The issue only seems to impact a select few users who are using Windows devices.
  • Ping (and other) requests using host name or FQDN fail.
  • Nslookup, however, succeeds and provides the correct A records.
  • A sniffer on the FortiGate showed DNS queries from the client being forwarded to the DNS server, and the replies then forwarded to the client without issue.
  • A packet capture on the client showed, even in the non-working scenario, that the DNS request was sent and a valid reply received from your internal DNS server.

If the above symptoms match your scenario, this is generally caused by the following:

  • Where users are receiving IPv6 DNS servers from their home ISP. I recommend trying to disable IPv6 on the user’s device and see if that helps. If it does, you need to enable the DisableParallelAandAAAA setting (i.e. disable ParallelAandAAAA lookups). For this setting, the value is 0 to enable, 1 to disable DNS A and AAAA queries from executing in parallel on all configured DNS servers, with the fastest response being theoretically accepted first. This can explain the intermittent nature of the DNS queries, where in some cases user lookups to your internal DNS servers will “lose the race” to the user’s ISP IPv6 DNS servers, and the client will accept the first response which says the name doesn’t exist.
  • You can also look at turning off smart multi-homed name resolution.

I won’t go in to further detail, but hopefully this gives you a couple ideas.

3

Disable IPv6 on computer

4

Irregular issues like this may well be due to an IP conflict. If it’s only two users - and if it comes to it - it may be easiest to walk them through changing their IP space at home. Sounds crazy, but chances are there’s nothing on their network that needs a dedicated IP and their laptop, roku, thermostat, echo, and toaster will all work just as well with 192.168.123.0/24 rather than 192.168.0.0/24 (or .1.0/24).

5

It’s probably easier to configure an OpenVPN box. The FortiClient is practically unusable.

6

Are there any differences in how the two users are connecting? ie mac vs Windows, they use other vpns, they are in a different group

7

as other say, try to change the network block on the user side, if not, you can do a separete portal/group for this 2 user with others rules, like nat some services, I don’t remember if the new versions let you do that.

​

which network are you using in the vpn pool? default?

8

Last vpn client sucks, try on these client the 6.2.6 version.

9

Thankyou so much for this post! I was about to sack off Fortclient as our VPN solution because of this issue!

10

Very well written and comprehensive post, thank you.

Your first presumption seems to have been correct - disabling IPv6 on said user’s machine fixed it. Currently, I’m in the process of rolling out a GPO that will cause Windows to prefer IPv4 over IPv6. Will update here how that goes.

If that fixes it I will leave it at that. If it doesn’t I’ll research your other remark about enabling the DisableParallelAandAAAA setting. Thank you for your help!

11

DisableParallelAandAAAA

Regy_key for disabling DisableParallelAandAAAA worked out fine, turning off smart multi-homed name resolution didnt change the behavoir.

12

Thank for raising concern. We were struggling to understand this issue which occurred after turning on the DNS split tunnel on Forticlient SSL VPN. For me Disabling IPv6 has fixed the issue.

13

My observings 100% match your analysis. DisableParallelAandAAAA fixes the issue, while turning off smart multi-homed does not.

14

Thanks - this fixed it.

15

Thank you, this was my issue as well I appreciate you posting this.

16

If you are an IT pro, you shouldn’t be doing that as a long term solution. IPv6 is required for long term connectivity. Best to start implementing now.

17

Yes, I had that thought. The guy I’m currently investigating is a fellow system engineer (though working in another area) so we’ve already done these steps. Initially, he had a high DHCP range and the DNS was theoretically in that range, but he has since changed his DHCP range to a much lower one. Besides, the first thing I did was ask them to use a hotspot since, on Android, these default to 192.168.43.0/24. That being said I’ll do some wiresharking on his end this afternoon to see what comes of it. I’m somewhat convinced it’s a client side issue. Perhaps there are some minor differences between these devices despite them being centrally managed. Our solution is… wonky sometimes. But hey, thanks!

18

No, it’s identical. We use a certificate based VPN with a non-exportable certificate pushed through a GPO so that people can only connect using their company laptops. Both are on Windows and everything is identical on a superficial level.

19

This is probably old but we are also using forticlient registered 6.x and getting DNS stuck on all new networks. Not sure why it’s happening more frequently than it used to. So disable ipv6 is the only fix? Does the version 7 fix it? Has anyone tested this?

20

I have this issue on a 60E running version 7.2.4 OS, but the only client having the issue of resolving DNS is a chromebook. I can connect the VPN, but when I try to RDP to a Windows box in the office I can’t resolve the hostname. I can however, ping the IP address, and I can RDP using the IP address. Initially it worked when I first got the chromebook, but stopped a month later. Anyone have a fix for this issue??