The most common transition method for IPv6 (that is: how to enable IPv6 on a network that does not have a native IPv6 connection to the Internet) is a “6in4” tunnel. Other tunneling methods such as Teredo or SixXS are found on different literatures as well. However, another method that is not often explained is to tunnel the IPv6 packets through a normal VPN connection. For example, if the main office has a native IPv6 connection to the Internet as well as VPN connections to its remote offices, it is easy to bring IPv6 subnets to these stations. Here comes an example with two Palo Alto firewalls.
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.
Just a short post this time, but an interesting fact concerning different Internet Service Providers (ISPs) and their routing to/from other countries. I have a customer in Germany that has a remote office in France, connected via a site-to-site VPN. Around April last year the french office decided to change the ISP to a cheaper competitor that offers the same speed/bandwidth and therefore has no disadvantages… Well, I disagree.
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.
Ähnlich zum dem Site-to-Site VPN Throughput Test der FortiGate Firewalls wollte ich mal den FRITZ!Boxen auf den Zahn fühlen und herausfinden, in wie fern sich der VPN-Durchsatz bei den Modellen unterscheidet, bzw. welche Rolle die ausgewählten Verschlüsselungsverfahren spielen. Getestet habe ich eine (etwas ältere) FRITZ!Box 7270v3 mit FRITZ!OS 06.06 sowie eine (neuere, obgleich nicht Topmodell) FRITZ!Box 7430 in Version 06.30. Als VPN-Endpunkt auf der Gegenseite habe ich eine FortiGate Firewall genommen. Getestet wurde das reine Routing/NATting sowie verschiedene Phase 2 Proposals mit dem Netzwerk Tool Iperf.
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.
A common mistake when analyzing network speed/bandwidth between different applications and servers is to fully rely on the mere size of the files being transferred. In fact, one big file will transfer much faster than thousands of small files that have the same accumulated size. This depends on the overhead of reading/writing these files, building TCP/IP sessions, scanning them for viruses, etc. Furthermore, it is application dependent.
I built a small lab with an FTP server, switch, firewall, and an FTP client in which I played a bit with different file sizes. In this blog post I am showing the measured transfer times and some Wireshark graphs.
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.
Some time ago I published a post introducing ntopng as an out-of-the-box network monitoring tool. I am running it on a Knoppix live Linux notebook with two network cards. However, I have a few customers that wanted a persistent installation of ntopng in their environment. So this is a step-by-step tutorial on how to install ntopng on a Ubuntu server with at least two NICs.
When using a multilayer firewall design it is not directly clear on which of these firewalls remote site-to-site VPNs should terminate. What must be considered in such scenarios? Differentiate between partners and own remote offices? Or between static and dynamic peer IPs? What about the default routes on the remote sites?
Following is a discussion about different approaches and some best practices. Since not all concepts work with all firewall vendors, the following strategies are separated by common firewalls, i.e., Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, Palo Alto.
Since a few weeks I am using Tufin SecureTrack in my lab. A product which analyzes firewall policies about their usage and their changes by administrators (and much more). Therefore, the first step is to connect the firewalls to SecureTrack in two directions: SSH from SecureTrack to the device to analyze the configuration, as well as Syslog from the device to SecureTrack to real-time monitor the policy usage.
This blog post shows the adding of the following firewalls into Tufin: Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, and Palo Alto PA.
A few weeks ago I constructed an MRTG/Routers2 template for the Fortinet FortiGate firewalls. I am using it for monitoring the FortiGate from my MRTG/Routers2 server. With the basic MRTG tool “cfgmaker” all graphs for the interfaces are generated automatically. My template is an add-on that appends graphs for CPU, memory, and disk usage, as well as connections and VPN statistics. Furthermore, it implements the ping statistics graph and a “short summary”, which only shows the system relevant graphs.
This blog post is a list of common troubleshooting commands I am using on the FortiGate CLI. It is not complete nor very detailled, but provides the basic commands for troubleshooting network related issues that are not resolvable via the GUI. I am not focused on too many memory, process, kernel, etc. details. These must only be used if there are really specific problems. I am more focused on the general troubleshooting stuff.