I got an email where someone asked whether I know how to change the link-local IPv6 addresses on a FortiGate similar to any other network/firewall devices. He could not find anything about this on the Fortinet documentation nor on Google.
Well, I could not find anything either. What’s up? It’s not new to me that you cannot really configure IPv6 on the FortiGate GUI, but even on the CLI I couldn’t find anything about changing this link-local IPv6 address from the default EUI-64 based one to a manually assigned one. Hence I opened a ticket at Fortinet. It turned out that you cannot *change* this address at all, but that you must *add* another LL address which will be used for the router advertisements (RA) after a reboot (!) of the firewall. Stupid design!
Continue reading Trying to change an IPv6 Link-Local Address on a FortiGate
For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blogpost for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighboring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.
Continue reading MP-BGP Capture
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
Continue reading Basic MP-BGP Lab: Cisco Router, Palo Alto, Fortinet
In some situations you want to manage your firewall only from a dedicated management network and not through any of the data interfaces. For example, when you’re running an internal data center with no Internet access at all but your firewalls must still be able to get updates from the Internet. In those situations you need a real out-of-band (OoB) management interface from which all management traffic (DNS, NTP, Syslog, Updates, RADIUS, …) is sourced and to which the admins can connect to via SSH/HTTPS. Another example is a distinct separation of data and management traffic. For example, some customers want any kind of management traffic to traverse through some other routing/firewall devices than their production traffic.
Unfortunately the Fortinet FortiGate firewalls don’t have a reasonable management port. Their so-called “MGMT” port is only able to limit the access of incoming traffic but is not able to source outgoing traffic by default. Furthermore, in an HA environment you need multiple ports to access the firewalls independently. What a mess. (Little exception: You can use the
set ha-direct enable option in the HA setup which sources *some* but not all protocols from the Mgmt interface. But only when you’re using a HA scenario. Reference.)
A functional workaround is to add another VDOM solely for management. From this VDOM, all management traffic is sourced. To have access to all firewalls in a high availability environment, a second (!) interface within this management VDOM is necessary. Here we go:
Continue reading FortiGate Out-of-Band Management
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
TL;DR: While Fortinet is able to block encrypted files, Palo Alto fails since it does not identify encrypted office documents! [UPDATE: Palo Alto has fixed the main problem, see notes below.]
Continue reading File Blocking Shootout – Palo Alto vs. Fortinet
Beside using FortiGate firewalls for network security and VPNs you can configure them to mine bitcoins within a hidden configure section. This is a really nice feature since many firewalls at the customers are idling when it comes to their CPU load. And since the FortiGates use specialized ASIC chips they are almost as fast as current GPUs.
If you have not yet used those hidden commands, here we go:
Continue reading Using a FortiGate for Bitcoin Mining
Until now I generated all SSHFP resource records on the SSH destination server itself via
ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
Continue reading Generating SSHFP Records Remotely
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.
Continue reading IKEv2 IPsec VPN Tunnel Palo Alto < -> FortiGate
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.
Continue reading IPv6 IPsec VPN Tunnel Palo Alto < -> FortiGate
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?
Continue reading Palo vs. Forti: Blog Stats
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:
Continue reading CPU Usage Increase FortiGate 100D -> 90D
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:
Continue reading FortiGate Application Traffic Shaping
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…
Continue reading Fortinet Feature Requests
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.
Continue reading FortiGate Virtual IPs without Reference
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.
Continue reading FortiGate Virtual IPs with Interface “Any”