Standing up a new 40f and was testing out the connection to make sure everything was good before boxing it up, and was unable to browse once DNS filter was enabled. DNS status page shows the DNS Filter Server as Unreachable. Originally was using 18.104.22.168, and changed to 22.214.171.124 to confirm it wasn't just one server. When looking at the DNS filter settings, the service license appears to be blank/unset. Web Filtering is definitely licensed though.
Is there anything I can check that I might have missed? It's a pretty vanilla setup. None of the docs seem to line up with how the output looks.
I've spent quite a bit of time fiddling about with this too. I'm currently running 6.4.4 on a Fortigate 60E, not using the Fortiguard DNS servers (using my ISP DNS servers) and enforcing DNS over TLS.
The new prefered option seems to be the anycast network (listed as the "deafult Fortiguard access mode" in the 6.4.4 admin guide).
The Fortigaurd anycast servers were enabled in FortiOS sometime back- but I got the impression the anycast servers were still being rolled out in the background? Certainly my experience suggested it was perhaps not completely deployed.
I had fallen back to anycast disabled (ie using non-anycast) and using HTTPS over port 8888. That seemed to be reliable and stable for me in terms of SDNS and etc.
This thread prompted me to have another look at anycast and see if I could get it working.
This reference states Secure DNS as being on the anycast domain name of "globalsdns.fortinet.net". For me (near London UK) that resolves too 126.96.36.199.
So, if I try the following config:-
config system fortiguard
set fortiguard-anycast enable
set fortiguard-anycast-source fortinet
set protocol https
set port 443
set anycast-sdns-server-ip 0.0.0.0
set anycast-sdns-server-port 853
On the positive side with this configuration (using anycast) shows really good ping times to the "web filter" and "outbreak prevention" servers of about 19ms (previously had been up to 180ms). The IP address indicated is 188.8.131.52 (which the globalguardservice.fortinet.net shown in the reference above resolves too).
So, how did you get it all working Tristan? Are you able to share you final config perhaps?
I might raise a ticket and ask some quesiton about this too.
This is the output from one of the FortiGates we have on 6.4.3. Perhaps 6.4.4 has had a regression? Don't have one on hand to test at a newer version. There's no customized config for SDNS. We've had to failopen SDNS for a reason other than licensing: the HTTPS servers are just terrible and majority of the time return a rating error and there is no option for UDP on 6.4 train
Our issue on 6.4.4 with DNS filter licence server is related to the self originating trafic. Trafic is going to the Fortinet DNS filter server on ramdom interfaces. We use SD-WAN with a default route and multiple wan and vpn tunnels under SD-WAN. It seems like Fortigates handle self originating trafic differently since 6.2+. It's possible since then to set the interface for sdwan for different services (Logs, LDAP, Radius, etc) with the CLI command set interface-select-method sdwan. Even if I force sdwan for the Fortiguard service the DNS filter licence server goes out on ramdom interfaces. I have an open case about this and I believe it's a firmware bug.
Is there a way to Force SD-WAN routing decisions with interfaces priority or something like that?
It seems like the self originating trafic doesn't follow the sd-wan rules anymore exept for services that has the set interface-select-method sdwan command applied and it looks like the DNS filter licence server isn't under the Fortiguard service.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.