And one more IPsec VPN post, again between the Palo Alto Networks firewall and a Fortinet FortiGate, again over IPv6 but this time with IKEv2. It was no problem at all to change from IKEv1 to IKEv2 for this already configured VPN connection between the two different firewall vendors. Hence I am only showing the differences within the configuration and some listings from common CLI outputs for both firewalls.
Towards the global IPv6-only strategy ;) VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP.
While it was quite easy to bring the tunnel “up”, I had some problems tunneling both Internet Protocols over the single phase 2 session. The reason was some kind of differences within the IPsec tunnel handling between those two firewall vendors. Here are the details along with more than 20 screenshots and some CLI listings.
I want to talk about a fun fact concerning my blog statistics: Since a few years I have some “CLI troubleshooting commands” posts on my blog – one for the Palo Alto Networks firewall and another for the FortiGate firewall from Fortinet. If you are searching on Google for something like “palo alto cli commands” or “fortigate troubleshooting cli” my blog is always listed amongst the first 2-4 results.
But for some reasons the article for Fortinet has much more hits. I don’t know why but I have two different ideas. What do you think?
A few weeks ago I swapped a FortiGate 100D firewall to a 90D firewall. The 100D was defective and needed to be replaced. Since the customer only has a 20 Mbps ISP connection, I thought that a FortiGate 90D would fit for the moment, since it has a firewall throughput of 3,5 Gbps, compared to the lower value of 2,5 Gbps from the 100D.
Indeed, it worked. However, the CPU usage increase was huge, almost related to the NGFW throughput. Here are some graphs:
This is a really cool and easy to use feature of the FortiGate firewall: the traffic shaper. Once an application category uses too much traffic, the bandwidth consumption can be decreased with it. Just about three clicks:
I really like the FortiGate firewalls. They are easy to manage and have lots of functionality. However, I am also aware of some other firewall products and therefore have some feature requests to Fortinet that are not currently implemented in their firewalls. I am sometimes forwarding these FRs to the Fortinet support or to an SE, but they are not really interested in that. ;( So here is a list of my ideas that could improve the firewall. Hopefully/maybe some of them will be implemented one day…
Migrating from Juniper ScreenOS firewalls to FortiGates, there are some differences to note with static NATs, i.e., Mapped IPs (MIPs) on a Netscreen and Virtual IPs (VIPs) on a FortiGate. While the Juniper MIPs on an interface are always used by the firewall whenever a packet traverses the interface, the virtual IP objects on a FortiGate must be used at least once in the security policy before they are really used by the firewall.
On the FortiGate firewall, address objects and virtual IPs (VIPs) can be set up with an interface. For address objects this has no technical relevance – the address objects simply only appear on policies if the appropriate interface is selected. But for virtual IPs, this setting has relevance on how connections are NATed. This can be problematic.
I was interested in the performance of my FortiGate firewall when comparing IPv4 and IPv6 traffic. Therefore I built a small lab consisting a FortiWiFi 90D firewall and two Linux clients running Iperf. I tested the network throughput for both Internet Protocols in both directions within three scenarios: 1) both clients plugged into the same “hardware switch” on the FortiGate, 2) different subnets with an “allow any any” policy without any further security profiles, and finally, 3) activating antivirus, application control, IPS, and SSL inspection.
Triggered by a customer who had problems getting enough speed through an IPsec site-to-site VPN tunnel between FortiGate firewalls I decided to test different encryption/hashing algorithms to verify the network throughput. I used two FortiWiFi 90D firewalls that have an official IPsec VPN throughput of 1 Gbps. Using Iperf I measured the transfer rates with no VPN tunnel as well as with different IPsec proposals.
I first ran into really slow performances which were related to the default “Software Switch” on the FortiGate. After deleting this type of logical switch, the VPN throughput was almost as expected.
This is a step-by-step tutorial for configuring a high availability cluster (active-standby) with two FortiGate firewalls. Since almost all firewall vendors have different principles for their HA cluster, I am also showing a common network scenario for Fortinet.
I am still a bit confused about the different switch types a FortiGate firewall is able to handle. While there are a lot of information on the Internet about the “internal-switch-mode” of “switch/interface“, I have not found any good information about the differences between the “Hardware/Software/VLAN” switch types that are configured via the GUI or via the “virtual-switch-vlan enable” CLI command. Though I still don’t know exactly all differences, I am trying to explain some of them here.