![]() ![]() 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. 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. If it does, you need to enable the DisableParallelAandAAAA setting (i.e. I recommend trying to disable IPv6 on the user's device and see if that helps. ![]() Where users are receiving IPv6 DNS servers from their home ISP.If the above symptoms match your scenario, this is generally caused by the following: 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.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.Nslookup, however, succeeds and provides the correct A records.Ping (and other) requests using host name or FQDN fail.The issue only seems to impact a select few users who are using Windows devices.The issue appears to be intermittent in nature.Communication via IPv4 address still works without issue.Clients connected to the SSL VPN are sometimes unable to resolve internal DNS queries.So, it's with some likelihood a clientside problem. On the local client I see in wireshark under "Internet Control Message Protocol" the following:Ĭhecksum is correct and good, though. Xxx.xx.xx.1 (client) -> .100 (dns): icmp: xxx.xx.xx.1 (client) udp port 55671 unreachable Do you perhaps have an idea on what I could try / examine next or what I could do to solve this?ĮDIT: Some more tracing and wiresharking reveals the following (on the Firewall): Other than that I don't see any irregularities. This seems normal to me.Īdditionally, 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. I've tried to use the CLI sniffer utility, but there, I only see 4 requests TO the firewall, and 2 requests back. However, when contrasted with my own logs, I often see "Accept: IP connection error" on these requests. The VPN correctly sets the DNS on all of their connections and I can see the DNS requests in the firewall log. These two users are often not able to resolve hostnames. After setting a DNS suffix through the CLI everything works as intended for all but 2 users. ) networks so that the routes of the VPN have a higher specificity, thus capturing all 192.168.1.x requests. First, we had issues with users who were in the 192.168.1.0/24 network at home due to route specificity. Users use the newest FortiClient version. It's a FortiGate 60F on v6.4.4 build 1803 (GA). This seems to happen every 10 minutes or so. A few users, however, can sometimes not resolve hostnames. For the majority of users this works without a hitch. Recently, my company migrated to a FortiGate firewall and use the newest FortiClient VPN to allow our users to connect. Sharing dumps violates a reddit global rule and may result in a site-wide ban.ĮDIT: Solved! Disabling IPv6 as suggested by Slushmania and Craptcha fixed the issue. Posting brain or answer dumps for Fortinet certifications is prohibited as they are copyrighted material. What you have already tried as part of your troubleshooting process.Version and type of software being impacted (i.e.Some examples of useful information are the following: Next, please provide us as much information about your problem as you possibly can. If you're having a problem with a Fortinet product, first, make sure you submit your request to Fortinet TAC if you have a valid support contract. Here you can ask for help, share tips and tricks, and discuss anything related to Fortinet and Fortinet Products. Fortinet is a global leader and innovator in Network Security.
0 Comments
Leave a Reply. |