Fortinet’s Fortigate firewalls have amazing performance for the dollar, all thanks to their strength in ASIC design: They use custom hardware chips to accelerate everything from straight packet-slinging to encryption to content inspection.
When that hardware acceleration switches off, you may find yourself with terrible performance and CPU spikes. This article aims to document some of the “gotchas” I am aware of.
Step one: Docs. These are your friend. The hardware acceleration guide and the Cookbook entry on accelerated content inspection are good ones to bookmark. They’ll be your “source of truth” unless your hardware shows you otherwise.
Gotcha: Crypto Primitives
Which “cryptographic primitives” are accelerated depends on the generation of Fortigate firewall you are using. For example, the “C” series does not accelerate SHA-256, but does accelerate SHA-1. Having all your IPSEC tunnels hit CPU hurts.
You are in the clear on “D” series and above, which means as of 2019, you’re not terribly likely to encounter this issue with the most popular primitives. Still, before deciding on a standard for your VPNs, check the acceleration guide.
Gotcha: Inter-VDOM links
We had FTP transfers that traversed VDOMs completely kill our firewall, and we couldn’t make sense of it. It turns out, inter-VDOM links on NP4 and earlier processors aren’t accelerated at all. On NP6, they can be accelerated, if you took the trouble to configure that. Two accelerated inter-VDOM links with two interfaces each are available. The acceleration guide explains how to configure that on NP6.
If you are on hardware that does not accelerate inter-VDOM links, or you’re out of accelerated links, you do have the option of using accelerated hardware ports instead. Assign a (pair of) ports to each VDOM, and cable them together. Presto, accelerated inter-VDOM link that actually flows over physical interfaces. It’s not pretty, but sometimes it’s the only solution.
Gotcha: Proxy Mode
This one is simple. In proxy mode, content inspection isn’t accelerated. Use flow mode instead. This does put a bit of a crimp in the “our inspection is superior because we can proxy” messaging by Fortinet.
Since I had this statement challenged, here is the documentation I use to come to that conclusion.
“Firewall sessions that include proxy-based security profiles or a mixture of flow-based and proxy-based security profiles are never offloaded to network processors and are always processed by the FortiGate CPU.”, stated in the offloading Cookbook guide.
The same language is in the acceleration guide: “Firewall sessions that include proxy-based security profiles are never offloaded to network processors and are always processed by the FortiGate CPU”
Gotcha: Softswitch
Any traffic traversing a softswitch won’t be accelerated. The only environment where this is likely to matter is a SoHo setup with one of the smaller SoC-based Fortigates, anything below a FG-100. In a SoHo environment, it can be desirable to have WiFi and LAN on the same subnet, so that home systems can detect each other. A softswitch offers an easy solution, and also happens to switch off acceleration entirely.
Even with acceleration off, the performance of a SoHo Fortigate is often more than sufficient for what little traffic that environment generates.
If you’d like to use acceleration, simply “dump” the WiFi traffic onto the wire, that is, configure the SSID for the home network in bridge mode, not tunnel mode. You can even configure that bridged traffic to use VLAN tagging, if you’d like to keep the CAPWAP AP subnet and the home subnet separate.
And use the hardware switch built into the SoHo Fortigates for the built-in LAN ports. Without a softswitch, traffic will be accelerated. In the GUI, you can see your nTurbo and SPU sessions: If they’re 0, you’re not accelerating anything.
As this is configured per SSID, you can still have a second SSID in tunnel mode for IoT and guest traffic. In my own home, IoT devices and guests are on a tunneled SSID that only has access to the Internet; and WiFi printers are on a bridged SSID that shares a subnet with the wired LAN, making it easy to discover these printers from the PCs in the household.
Thorsten on (mostly) Tech 