Once more some throughput tests, this time the Palo Alto Networks firewalls site-to-site IPsec VPN. Similar to my VPN speedtests for the FortiGate firewall, I set up a small lab with two PA-200 firewalls and tested the bandwidth of different IPsec phase 2 algorithms. Compared to the official data sheet information from Palo Alto that state an IPsec VPN throughput of 50 Mbps, the results are really astonishing.
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.
Ä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.
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.
How to route traffic inside an IPv6 site-to-site VPN tunnel if one side offers only dynamic IPv6 prefixes? With IPv4, the private network segments were statically routed through the tunnel. But with a dynamic prefix, a static route is not possible. That is, a dynamic routing protocol must be used. Here is an example of how I used OSPFv3 for IPv6 between my VPN endpoints.
In detail, I have a home office with a dual stack ISP connection. However, this connection has a dynamic IPv6 prefix: After every reboot or lost connection of the firewall, I get a new IPv6 prefix. This is really bad for building a site-to-site VPN to the headquarter. Since I don’t want to use any kind of NAT/NPTv6 with unique local addresses, I am talking OSPFv3 over the VPN tunnel in order to route the dynamic prefix range (global unicast) via the tunnel.
With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!
However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!
The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)
Hier kommt ein kurzer Guide wie man ein Site-to-Site VPN zwischen einer FortiGate Firewall und einer AVM FRITZ!Box aufbaut. Anhand von Screenshots zeige ich die Einrichtung der FortiGate, während ich für die FRITZ!Box ein Template der *.cfg Konfigurationsdatei bereitstelle.
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. Even other tunneling methods such as Teredo or SixXS are found on different literatures. However, another method that is not often explained is to tunnel the IPv6 packets through a 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 is how I did it with some Juniper SSG firewalls:
Es geht in eine weitere Runde bei den VPNs von und zur FRITZ!Box. Nach den unglücklichen Änderungen in Version 06.20 hat AVM wieder ein paar Phase 2 Proposals hinzugenommen, die komplett ohne Kompression laufen. Somit ist es wieder möglich, die FRITZ!Box im Aggressive Mode VPN-Verbindungen zu diversen Firewalls aufbauen zu lassen. Komisch nur, dass noch nicht alles ganz wie erwartet funktioniert. Hier kommen meine Testergebnisse.
Similar to my test with Diffie-Hellman group 14 shown here I tested a VPN connection with the elliptic curve Diffie-Hellman groups 19 and 20. The considerations why to use these DH groups are listed in the just mentioned post – mainly because of the higher security level they offer. I tested the site-to-site IPsec connections with a Juniper ScreenOS firewall and a Fortinet FortiGate firewall. (Currently, neither the Palo Alto nor the Cisco ASA support these groups.)
Following is a step-by-step tutorial for a site-to-site VPN between a Fortinet FortiGate and a Cisco ASA firewall. I am showing the screenshots of the GUIs in order to configure the VPN, as well as some CLI show commands.
This blog post shows how to configure a site-to-site IPsec VPN between a FortiGate firewall and a Cisco router. The FortiGate is configured via the GUI – the router via the CLI. I am showing the screenshots/listings as well as a few troubleshooting commands.
This is a small tutorial for configuring a site-to-site IPsec VPN between a Palo Alto and a FortiGate firewall. I am publishing step-by-step screenshots for both firewalls as well as a few troubleshooting CLI commands.
Pre-shared keys (PSK) are the most common authentication method for site-to-site IPsec VPN tunnels. So what’s to say about the security of PSKs? What is its role for the network security? How complex should PSKs be? Should they be stored additionally? What happens if an attacker catches my PSKs?
I am listing my best practice steps for generating PSKs.