Fortiguard Vs Fortiguard Anycast

[Billi Mayhue]

Useof a hardcoded cryptographic key in the FortiGuard services communication protocol may allow a Man in the middle with knowledge of the key to eavesdrop on and modify information (URL/SPAM services in FortiOS 5.6, and URL/SPAM/AV services in FortiOS 6.0.; URL rating in FortiClient) sent and received from Fortiguard servers by decrypting these messages.

Upgrade to FortiOS 6.0.8 and upper version or 5.6.12 then manually change the configuration to use TLS as communication protocol with FortiGuard servers after upgrade (see -release-notes/901852/fortiguard-protocol-and-port-number) or do a fresh install to get the new default which is the TLS based system.

For AV communication exposure on FortiOS 6.0 and above; the only impact is if outbreak protection is enabled in the antivirus profile settings. This is the only part of AV which makes a real-time FortiGuard request.

Upgrade to FortiClientWindows 6.2.0 or FortiClientMac 6.2.2 then change EMS configuration in the Endpoint Profile to use "FortiGuard Anycast". The new option is provided for Web Filter tab, as well as System Settings tab.

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 173.243.140.16, and changed to 208.91.112.220 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.

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 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.

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 .......end

That seemed to work initially. But I can see from "diag test app dnsproxy 3" the "licence" issue Tristan noted. Further, this link in the admin guide ( -guide/150448/troubleshooting-for-d...) seems to confirm this config isn't working for SDNS.

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 173.243.140.16 (which the globalguardservice.fortinet.net shown in the reference above resolves 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.

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.

Most critical of them is Web Filter rating query - if your Fortigate cannot get answer what category the web site belongs to, access to this web site will be blocked by default. It means that if for any reason Fortigate cannot reach Fortiguard servers and it has security rules with Web Filtering by Category configured - those rules will BLOCK users access to ANY website, not just malicious ones.

First, check status of license/subscription and FortiGuard connection status in System -> FortiGuard - the Web Filtering status should be in green. This checks subscription license status, but not always detects connection to the FortiGuard status. If you see it red, it is most probably a license/subscription issue to be checked with Fortinet TAC, as subscription checks are done once in a while and are cached. To check actual connectivity to the FortiGuard servers - on the same page, under Filtering subsection, there is Test Connectivity button to push. It should return status as Up/green. Also pay attention to the widget on the same page in the right bottom corner FortiGuard Filter Rating Servers, it shows real time stats and IP addresses of the servers the Fortigate is trying to reach. If timings are unusually high and in red, there could be network connectivity problem, we will look at next.

Even better check is to run ping exe ping to all the hostnames above to see if the Fortigate can resolve AND can reach them. The most important of them being service.fortiguard.net.

Here:

Status - shows if Web Filtering as a service is enabled.

Protocol - via what protocol this Fortigate is trying to reach FortiGuard servers (more on this below).

Anycast - whether this Fortigate is trying to reach Anycast servers of FortiGuard (more on this below).

Server List - actual list of FortiGuard servers that this Fortigate was/is trying to reach. Here most important is status legend:

- F: failed, bad - Fortigate tried few times to reach this server to no avail. Note that it is bad only if ALL servers in the list have this status. It is OK if only few of the servers are unreachable.

- D: this server was successfully resolved from FQDN to its IP address, but it does not indicate its reachability yet.

- I: server to which Fortigate tries to initiate connection, most frequently goes with D,it does not indicate if a server is working or not yet.

- T: server was found, it answered, and is now being "timed", i.e. its answer time/RTT is being measured.

- TZ: Time Zone, while not a status indicator, Fortigate tries and prefers servers with the least time zone difference in hope of geographic proximity. Therefore, it is quite important to set correctly the time zone for your Fortigate.

Fortigate communicates for its functions with just one server at a time - the one on top of the list. The rest of the servers are being constantly monitored and their RTT, and packet loss measured. If the top-list server fails, it will be replaced with the next best one and so on. We do not have capability to influence this server list manually.

So if all servers in the list have F(ailed), what do we do next?. This may mean either all Fortiguard servers at the Fortinet side are down (less likely), or that this Fortigate has the problem of reaching them at the network level.

Fortigate can use several ports to talk to Fortiguard servers (or Fortiguard Distribution Network as they call it) - 53, 8888, 443, the default being 8888. The port 53 is a well known DNS protocol/port, only that Fortigate uses proprietary UDP/53 obfuscated/encrypted protocol to query the servers, and for this reason some IPS/anti-DDoS/etc protections on the way from Fortigate to FortiGuard may mark such traffic as malicious and drop it. You can check if it is the case by going to System -> FortiGuard -> Filtering and change (if set so) from port 53 to port 8888. On newer FortiOS versions (6.4 and up) they moved this to CLI only: config sys fortiguard then set port 538888443. So, as first debug measure it is recommended to try all possible ports and see if status of connection to the FortiGuard servers changes. Note about protocol I mentioned before - in 6.4 and newer they added option to force the communication to FortiGuard servers to be a valid HTTPS traffic, which is most likely to pass the Internet successfully. For this you have to enable it (in addition to setting port to 443) via CLI: config sys fortiguard, then set protocol https end.

Important note if you have VDOMs enabled - all communication to the Fortiguard network is initiated from management/root VDOM only! The frequent human error I've seen - someone by mistake changes management domain to the VDOM that has no/limited access to the Internet and as a consequence, it cannot reach FortiGuard network. Very common, indeed. To verify who is the management VDOM:

Anycast servers - starting with FortiOS 6.4 the default setting to reach FortiGuard is anycast. The intention was good - to improve reachability of FortiGuard servers, but unfortunately the implementation did not live up to the expectations. More often than not it actually creates a problem in reaching the Fortinet servers. It may improve in the future, but for now my advice is to disable anycast and switch back to unicast servers. You do so in CLI:

i have purchased a new fortigate 101e and it uses the fortiOS 6.0.6 and before i connect it to the internet i want to disable all connections to fortiguard servers and forti Distribution Network(FDN), our enviroment will use a manual updates for it and its services, so i have:

3a8082e126