Thursday, June 24, 2021

Tel: +44 (0)1525 850 440
Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

FortiGate Tips

This page provides useful tips for FortiGate firewall support.

The support tips here are primarily for CLI (Command Line Interface) accessible either via the console or SSH (SecureShell) or telnet. We assume you already have admin access to your firewall via the web (HTTPS) GUI.


FortiGate AV/IPS not working?

Via the CLI use command: diagnose test update info - to see useful messages on why AV/IPS updates may not be working. Often DNS or routing issues.


Want to kill a FortiGate daemon?

You can do that using the CLI use command: diagnose sys kill 9 <procid>  and procid can be found from CLI command: diagnose system top



FortiGate and DDos

Empirical research just published  in May 2014 suggests that, whilst overall DDoS attack volumes are increasing steadily, new attack vectors are also constantly being used by cybercriminals.

Researchers found that 79.8 percent of all attacks were 50 Mbps or less. In addition, although large size attacks get the most media attention, only 0.63 percent of all attack incidents were logged at 4 Gbps or more.

Perhaps most interestingly of all is that more than 90 percent of the observed attacks lasted 30 minutes or less - and that 63.6 per cent of all targeted victims are attacked more than once. This figure is in line with earlier figures from Neustar whose second annual report, entitled `DDoS Attacks & Impact Report - 2014: The Danger Deepens' - suggested  that once attacked, there is an estimated 69 percent chance of a repeat attack.

Delving into the report reveals that HTTP_FLOOD, TCP_FLOOD and DNS_FLOOD are the top three attack types - contributing to more than 87 percent of all attacks.

DNS_FLOOD attacks, however, significantly increased from 13.1 percent during the first half of the 2013 to 50.1 percent in the second half.

These _FLOOD attacks can all be mitigated using the FortiGate DoS Policy settings.


Securing SCADA Infrastructure - with FortiNet

Fortinet has a range of security solutions designed specifically for a SCADA environment and to secure the SCADA network.

Fortinet secures SCADA systems with a complete range of network security services designed specifically for SCADA including data leak prevention, wireless network security, intrusion protection, application control, secure remote access and firewalling services. With FIPS 140-2 and Common Criteria EAL4+ certification, GISS & Fortinet are an ideal partner to help you meet such critical security requirements.

FortiGate unified threat management provides true defence-in–depth capabilities to “virtually patch” vulnerable systems, minimising disruption to the SCADA network. With a wide range of products, Fortinet delivers protection to all areas of the network; from low-end appliances to directly protect RTU/PLU devices to powerful, high performance, low latency systems that aggregate VPNs from remote locations, protect control systems, and mitigate risk at network borders.

See this white paper for more information: FortiNet - Securing SCADA Infrastructure R2


FortiGates and Heartbleed Bug

An information disclosure vulnerability has been discovered in OpenSSL versions 1.0.1 through 1.0.1f that affects FortiGate (FortiOS) 5.0 and higher, FortiAuthenticator 3.0 and higher, FortiMail 5.0 and higher, FortiVoice, and FortiRecorder.

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

See: on how to mitigate on FortiNet products and for more information.



To SSH to your firewall, make sure that SSH is enabled on the internal interface of your firewall (via FortiGate Web GUI go to System, Interface, Edit your internal interface (or equivalent), and check SSH option). Then load PuTTY (see Downloads) on your PC and connect PuTTY to your FortiGate, and enter username and password used on Web GUI.


Packet Sniffer

Is, undoubtedly the most powerful tool in debugging firewall issues. Want to see your PC the ping from your PC pass through your Fortigate? Easy, at the CLI prompt type:

diagnose sniffer packet any 'host and icmp' 4

The 'any' means any interface, and the 4 means show which interfaces the packets are arriving/departing to/from. So you might see something like:

Fortigate # diagnose sniffer packet any 'host and icmp' 4
filters=[host and icmp]
1.361873 internal in -> icmp: echo request <=== (Source IP -> Destination IP)
1.361955 wan1 out -> icmp: echo request
1.390291 wan1 in -> icmp: echo reply
1.390350 internal out -> icmp: echo reply

Notice in bold and underlined that the source IP on the way out to the internet has been NATed to public IP, and then the reply is reverse NATed.

Other examples you can use would be (note abbreviations):

diag snif packet port1 'port 8888 or (port 80 and host'

will show any traffic bound for port 8888, or any traffic that is bound for port 80 AND IP address

diag snif packet any '!host or !port 80' 

will show any traffic that is NOT (!) to or from IP address or is NOT port 80.


Google SafeSearch (Safe Search) not working via FortiGuard Web Filter

When searching over Secure Sockets Layer (SSL) HTTPS, the connection between the user and Google is encrypted. Because the connection is encrypted, the query rewriting techniques used by firewalls to enforce safe search will not work. So how do you force Google SafeSearch to work in a firewalled environment?

As a workaround, you may disable SSL using our No-SSL option.

To utilize the no SSL option for your network if in the UK, then configure two DNS forward lookup zones. One for, and add A record with no host name, set to IP address (the IP for Then do the same for

Google will not serve SSL search results for requests that is receive on this VIP

Customization and personalization is dependent on SSL availability, thus some features may be affected. Utilizing the NoSSLSearch VIP will not affect other Google services outside of Search. Logging into Google Apps and authenticating to different services will continue to work (and will occur over SSL).

For more see:


Apple IOS 7 and wifi devices not connecting

Recently Apple released an iOS 7 update for iPhones and iPads.  Since the release, customers have reported that iOS 7 devices are having issues connecting to their wireless networks.

This issue occurs if the Apple device believes it can’t access the Internet. As part of their normal operation, Apple devices make a secret WISPr request to see if the device can reach the internet. WISPr is actually a WiFi Alliance protocol, but Apple iOS and other devices use it to determine if the device is connected to Internet by sending a WISPr request to a pre-defined URL. If the URL isn’t reachable, the device assumes a captive portal login is needed and launches a web browser.

If the WISPr request is unsuccessful, the device responds with a message that it “cannot join the network”.  It seems that the URLs that the IOS 7 devices try to reach have changed.

If your Internet traffic passed through a content filter, it might be blocking access to these new URLs. These three URLs will need to be added to the content filter white list are:

To resolve the problem, simply add these two URLs to be allowed by your content filter. Once that’s done, the iOS 7 device should be able to join the wireless network successfully again.


Legacy Windows XP has come to end of life, our company still needs to use it - can I still use it securely through my FortiGate Firewall?

On Tuesday 8th April 2014 Microsoft pulled the plug on the 12 year old Windows XP operating system. But you still have legacy applications you need to run on this platform and access the internet securely via your FortiGate firewall.

Fortunately, end-of-support from Microsoft does not mean that an XP machine will suddenly stop working; rather, there will be no further upgrades to the system or updates of its antivirus features. But take a few precautions and you should be able to use this platform securely for a good while to come if really needed.

Switch from Microsoft's antivirus offering, MS Security Essentials, to a third-party alternative such as AVG Free (,which will keep itself up
to date. Ideally, say goodbye to Microsoft's email (Outlook Express) and browser software (Internet Explorer) too. Mozilla Thunderbird is an excellent email replacement; try Firefox as a browser. Both will help you transfer your contacts, bookmarks and other information.

For extra security, a firewall such as ZoneAlarm Free ( puts a layer of protection between you and the internet. And we'd advise that you change your default Windows XP login from an admin account to the more limited user account. That way, should any malware sneak past, it will be able to do far less damage. Find out how to do this at

Ultimately the event that will move you finally away from Windows XP is when your needed program stops working or a replacement demands a more recent version of Windows, or you can't find an XP-compatible upgrade component. Until then you should be fine with what we've suggested.