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.

Labor

Mein Labor sah wie folgt aus:

Die FRITZ!Box ist eine 7390 mit FRITZ!OS 06.30, während die Fortinet Firewall eine FortiWiFi 90D mit Version 5.2.2 ist. Wie im Internet üblich ist die FortiGate mit einer statischen IP-Adresse versehen (obgleich 1 zu 1 geNATet), während sich die FRITZ!Box hinter einer dynamischen IP verbirgt. Mit einem dynamischen DNS Dienst ist immerhin ein FQDN für die FRITZ!Box verfügbar.

Sehr praktisch bei FortiOS ist ja, dass bei IKE auch dann der Main Mode verwendet werden kann, wenn die Gegenstelle lediglich über eine dynamische IP (mit einem DynDNS Namen) verfügt. Sprich: Es ist nicht der Aggressive Mode nötig, um ein VPN zu bauen, und vorallem kann der Tunnelaufbau auch von der FortiGate selbst initiiert werden. (Exakt vergleichbar mit der Juniper SSG, die das genau so kann, siehe hier.)

FortiGate

Folgende Schritte sind seitens der FortiGate nötig. In den Beschriftungen unterhalb der Screenshots stehen weitere Details:

FRITZ!Box

Für die FRITZ!Box muss folgendes Template angepasst werden. Gelb markiert sind all die Zeilen, die zwingend angepasst werden müssen. Die Proposals für Phase 1 und 2 können natürlich auch anders gewählt werden, solange das Pendant bei der FortiGate stimmt (siehe hier für mehr Details bezüglich der Proposals der FRITZ!Box).

Hinweis: Dieses Template unterscheidet sich in einer Kleinigkeit von quasi allen anderen Templates, die hier auf meinem Blog sind: Es ist sowohl die localid als auch die remoteid vom Typ “fqdn”. In vielen anderen Beispielen habe ich hier bei der remoteid den Typ “ipaddr” gehabt. Dieser lässt sich auf der FortiGate leider nicht einstellen, da dort unter Verwendung einer IP-Adresse trotzdem ein String versendet wird. Daher ist hier bei der FRITZ!Box zwingend der fqdn nötig.

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "fortigate-vpn";
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 80.154.108.233;
                remote_virtualip = 0.0.0.0;
                localid {
                        fqdn = "fritzbox.webernetz.net";
                }
                remoteid {
                        fqdn = "blubb";
                }
                mode = phase1_mode_idp;
                phase1ss = "dh14/aes/sha";
                keytype = connkeytype_pre_shared;
                key = "RX-2RUz2UKpFiPXi6B6DJss5TWbW-DzvTMwc";
                cert_do_server_auth = no;
                use_nat_t = no;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.29.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.161.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
                accesslist = "permit ip any 192.168.161.0 255.255.255.0";
        }  ike_forward_rules =	"udp 0.0.0.0:500 0.0.0.0:500", 
								"udp 0.0.0.0:4500 0.0.0.0:4500";
	}

Es läuft …

wenn es grün leuchtet.

Wer mehr Infos zur VPN-Verbindung möchte, kann auf der FortiGate zum Beispiel mit den folgenden Befehlen Details herausfinden:

fd-wv-fw04 # get vpn ike gateway fritzbox

vd: root/0
name: fritzbox
version: 1
interface: wan1 6
addr: 172.16.1.6:500 -> 77.1.138.66:500
created: 1484s ago
peer-id: fritzbox.webernetz.net
peer-auth: no
IKE SA  created: 1/1  established: 1/1  time: 2260/2260/2260 ms
IPsec SA  created: 1/1  established: 1/1  time: 2190/2190/2190 ms

  id/spi: 27873 c0946dbb7e367bbf/98f5902234833225
  direction: initiator
  status: established 1484-1482s ago = 2260ms
  proposal: aes-256-sha1
  key: c24d006dcddd88db-561bdd168fb5ece9-fd87c497587cb16c-b0ccbb1302b38310
  lifetime/rekey: 3600/1817
  DPD sent/recv: 00016e13/00000000

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get vpn ipsec tunnel name fritzbox

gateway
  name: 'fritzbox'
  type: route-based
  local-gateway: 172.16.1.6:0 (static)
  remote-gateway: 77.1.138.66:0 (static)
  mode: ike-v1
  interface: 'wan1' (6)
  rx  packets: 2  bytes: 236  errors: 0
  tx  packets: 2  bytes: 168  errors: 3
  dpd: enabled/negotiated  idle: 5000ms  retry: 3  count: 0
  selectors
    name: 'fritzbox'
    auto-negotiate: disable
    mode: tunnel
    src: 0:192.168.161.0/255.255.255.0:0
    dst: 0:192.168.29.0/255.255.255.0:0
    SA
      lifetime/rekey: 3600/2121
      mtu: 1438
      tx-esp-seq: 3
      replay: enabled
      inbound
        spi: c97b3074
        enc:     aes  2cdc2d66d55ce60a9d0653e47045dc09495210ff01e4e164317407d19d8abd12
        auth:   sha1  a18c972688001670905a0de1d85e6383e79d4aad
      outbound
        spi: 4e200a54
        enc:     aes  d7a420011bf1b1e7408915e60a02e9eed4fdee6124bd9266d43a5e2f4e3f4ea2
        auth:   sha1  58f2788cf82545e5938a95fd421f5ab9828505b3
      NPU acceleration: encryption(outbound) decryption(inbound)

fd-wv-fw04 #
fd-wv-fw04 #
fd-wv-fw04 # get router info routing-table static
S*      0.0.0.0/0 [10/0] via 172.16.1.1, wan1
S       192.168.29.0/24 [10/0] is directly connected, fritzbox
S       192.168.121.0/24 [10/0] is directly connected, fd-wv-fw02
S       192.168.131.0/24 [10/0] is directly connected, fd-wv-fw03

For a basic remote access VPN connection to a Palo Alto Networks firewall (called “GlobalProtect”), the built-in VPN feature from Android can be used instead of the GlobalProtect app from Palo Alto itself. If the additional features such as HIP profiling are not needed, this variant fits perfectly.

I am showing a few screenshots and logs from the Android smartphone as well as from the Palo Alto to show the differences.

This post is very similar to the post about the iPhone. I am running a PA-200 with PAN-OS version 7.0.3. The phone is a Samsung Galaxy S4 Mini with Android version 4.4.2.

The GlobalProtect app from Palo Alto works without any problems if a correct Portal and Gateway are already configured. In order to use the native “IPSec Xauth PSK” on Android, the “X-Auth Support” must be enabled on the GlobalProtect Gateway, such as shown here in my post about the Linux vpnc client.

GlobalProtect App vs. Native VPN

The following Android screenshots show the configuration steps for the native IPsec VPN tunnel. The “IPSec Xauth PSK” type must be chosen:

Just for a comparison: The GlobalProtect app looks like that:

Palo Alto Logs

It is interesting to see the differences in the Palo Alto logs, i.e., the GlobalProtect Previous User, System Log and Traffic Log. Here are the differences:

That’s it.

The native Android IPsec VPN client supports connections to the Cisco ASA firewall. This even works without the “AnyConnect for Mobile” license on the ASA. If only a basic remote access VPN connection is needed, this fits perfectly. It uses the classical IPsec protocol instead of the newer SSL version. However, the VPN tunnel works anyway.

In this short post I am showing the configuration steps on the ASA and on the Android phone in order to establish a remote access VPN tunnel.

I am running a Cisco ASA 5505 with version 9.2(4). The Android smartphone is a Samsung Galaxy S4 Mini with Android 4.4.2.

Cisco ASA Config

The configuration steps on the ASA are mostly the same as for a classical VPN-Client connection profile:

Or the appropriate CLI commands:

ip local pool Pool_192.168.133.0 192.168.133.10-192.168.133.99 mask 255.255.255.0
!
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
!
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group5
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-AES-256-SHA ESP-AES-128-SHA
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev2 ipsec-proposal AES256
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
!
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication pre-share
 encryption aes-256
 hash sha
 group 5
 lifetime 28800
crypto ikev1 policy 30
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 28800
crypto ikev1 policy 90
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 28800
!
group-policy MainVPN internal
group-policy MainVPN attributes
 dns-server value 8.8.8.8 8.8.4.4
 vpn-tunnel-protocol ikev1 ssl-client
 default-domain value webernetz.net
!
tunnel-group MainVPN type remote-access
tunnel-group MainVPN general-attributes
 address-pool Pool_192.168.133.0
 default-group-policy MainVPN
tunnel-group MainVPN ipsec-attributes
 ikev1 pre-shared-key *****

Android IPsec PSK

This is how the VPN connection must be configured:

ASA Logs

After a connection establishment, the VPN session details on the ASA show details:

And, of course, via the CLI:

fd-wv-fw03# show vpn-sessiondb ra-ikev1-ipsec

Session Type: IKEv1 IPsec

Username     : weberjoh               Index        : 233
Assigned IP  : 192.168.133.10         Public IP    : 194.29.191.227
Protocol     : IKEv1 IPsecOverNatT
License      : Other VPN
Encryption   : IKEv1: (1)AES256  IPsecOverNatT: (1)AES256
Hashing      : IKEv1: (1)SHA1  IPsecOverNatT: (1)SHA1
Bytes Tx     : 138957                 Bytes Rx     : 483030
Group Policy : MainVPN                Tunnel Group : MainVPN
Login Time   : 15:46:24 CEST Mon Oct 26 2015
Duration     : 0h:14m:20s
Inactivity   : 0h:00m:00s
VLAN Mapping : N/A                    VLAN         : none
Audt Sess ID : c0a88201000e9000562e3cc0
Security Grp : none

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.

Of course, if there is only a single firewall in place, this discussion is not necessary at all. All VPN tunnels must solely terminate on this single firewall. You’re done. But most customers have at least a two-firewall strategy which is not a bad idea at all. While the first firewall is merely for stopping all unused IP connections and for allowing connections to the DMZ, the second firewall has next-gen features such as APT scanning, URL filtering, user recognition, etc. Normally, both firewalls have a default route directed to the Internet (if no proxies are used).

Who has a Static S2S Tunnel?

• Remote Offices: Locations that are owned by the same company. Mostly coming from static IP addresses. If the remote office has no local Internet breakout, it has a default route back to the headquarter. That is: all Internet traffic must be processed by the second, next-generation firewall (or web-proxy). The network behind this remote office can be considered as internal, but on another location. It should be treated in the same way os other internal traffic.
  
• Home Offices: Users that are working from home. Normally coming from dynamic IP addresses. No local Internet breakout -> all traffic must traverse through the second NGFW, too. (I.e., same as “remote office”, but from a dynamic IP address.)
• Partners: Other companies that must access certain services in the DMZ (such as servers or proxies). Almost coming from static IP addresses. No routing/ACLs for accessing the internal networks are required. That is: This traffic must not go through the second firewall.

The Problems

1. The first firewall has a default route to the Internet. Otherwise, no connections could be made from/to the firewall at all.
2. But for the remote- and home-offices, the traffic coming out of the VPN-interface need a default route to the second firewall (and not directly to the Internet). If all VPNs are terminated on the first firewall, this is not the case. -> The best approach is to have an own routing instance for the tunnel-interfaces with a default route to the second firewall.
3. Only a few firewall appliances implement the concept of “virtual routers” (Juniper ScreenOS, Palo Alto). For the FortiGate, policy-based forwarding can be used. For the Cisco ASA, none of these concepts work. Only a workaround can be used there (if it is not an option to buy a better firewall).

(Note that for some remote access VPN solutions, it is default to have two virtual routers / routing tables in the box. This is true, for example, for the Pulse Secure, formerly Juniper SA/MAG. With these devices, traffic coming out from the VPN has another default route than Internet traffic with its default route to the Internet.)

All following concepts describe the case in which the first firewall is from vendor X. It is not related to the second firewall.

Concept 1: Two Virtual Routers on the first firewall (Juniper, Palo Alto)

Both firewall vendors (Juniper ScreenOS and Palo Alto) have virtual routers implemented. That means, the “tunnel-interface” for the VPN can be on another virtual router with another default route. While the default virtual router can point to the Internet (for all outgoing connections and for terminating the VPN), the second virtual router (with the tunnel-interface in it) can point to the second firewall.

Concept 2: Policy-Based Routing/Forwarding (FortiGate)

Unluckily, the FortiGate has not virtual routers, but only virtual domains (vdoms). This is great for separating firewall instances, but does not solve the VPN problem here. However, it is possible to configure a policy route: All traffic coming out of the tunnel-interface has a “new” default route to the second firewall.

Concept 3: Partners on First, Remote Office on Second Firewall (Cisco ASA)

Cisco ASA has neither virtual routers nor policy-based routing. The only “concept” is to terminate the partners on the Cisco ASA and to allow the remote offices to access the second firewall for VPN termination. That is, the static IP addresses from the remote offices must be allowed in an ACL on the Cisco ASA to reach the second firewall directly. Note that it is NOT recommended to allow “from any” to the second firewall, which means that VPN connections from home offices (coming from dynamic IP addresses) will not work in this scenario. That’s definitely a major drawback.

Any Comments?

Please write a comment if I missed something or if you disagree with one of these concepts. Thanks a lot.

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.

Lab

My lab consists of the following components:

Both FortiWiFi 90D firewalls had the firmware version v5.2.5, build701. The two notebooks were booted with Knoppix 7.6.1 and used Iperf version 2.0.5. The “left” machine ran as the server with either:

iperf -s
iperf -s -u

while the “right” machine started Iperf with the following commands for different TCP and UDP tests:

iperf -c 192.168.10.10 -r
iperf -c 192.168.10.10 -r -P 8
iperf -c 192.168.10.10 -r -u -b 1000M

I tested the throughput without a VPN at all (only routing) and with a few different proposals (see table below). The Diffie-Hellman group for PFS was always set to 14. This is not related to the test results because it is only used for the key establishment and not for the actual symmetric encryption of the traffic.

I also switched the offloading of encryption to “enable” (refer to the Hardware Acceleration Guide), which did not change anything, either.

config system npu
    set enc-offload-antireplay enable
end

Furthermore, I tested the differences between a normal TCP test and the manual set of the TCP window size and buffer length with “-w 512k -l 512k”, such as shown here or here. But this made no differences, too, since Knoppix Linux seems to auto set the window size pretty optimal.

Results

These are the results. The first four tests are without a VPN. While the first two are without routing (simply plugged in both clients into the same software switch on the FortiGate), tests 3 & 4 are routed through the FortiGates. This was the first time at which I was really shocked about the bad performance of only 180 Mbit/s routing speed. Furthermore, almost all IPsec proposals ran at a speed of 86 MBit/s, which is only 9 % of the IPsec throughput listed in the data sheet.

The software switch was the problem!

After hours of investigating the slow VPN speed results, I tested the VPN without the software switch on the network ports side, which led to the following results (first column with a “Hardware Switch”, second column with a single interface):

Now the speed was quite acceptable, for the mere routing as well as for the VPN throughput. 940 MBit/s for routing through both FortiGate is almost realistic for TCP, and about 830 MBit/s for VPN encryption/decryption is realistic, too.

Here are the “single interface” results in a graph. Only the 3DES tests are a bit slower than all the other ones:

Conclusion

Well, it was my fault that I left the default software switch in place. I should have know better. However, it was the default setting on this FortiWiFi devices.

At the end, the VPN throughput between those FortiGates was really acceptable.

Ä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.

Ein paar mehr Details bezüglich des Testaufbaus kann man in dem vorherigen Artikel von mir durchlesen. Hier wurde nur die eine FortiGate als Router umfunktioniert und dahinter die jeweilige FRITZ!Box gesetzt. Auf den Testnotebooks lief wieder Knoppix.

Labor

Folgende Einstellungen nahm ich auf der FRITZ!Box vor:

• Internetzugang über LAN 1, Internetverbindung selber aufbauen
• Übertragungsgeschwindigkeit auf 100.000 kbit/s für beide Richtungen gesetzt
• Portfreigabe “Exposed Host” an Test-Client IP
• WLAN deaktiviert
• VPN zur FortiGate gemäß dieser Vorlage aufgebaut
• An der FortiGate zwischen 3DES und AES256 in Phase 2 manuell gewechselt, bzw. auch mit “nur Routing” ohne VPN getestet.

Logisch sah das Labor dann so aus:

Physikalisch in etwa so:

Testergebnisse

Dies waren meine Testergebnisse (TCP):

Bzw. in Rohform (TCP und UDP):

Ohne VPN liefert die 7270 einigermaßen gute Ergebnisse. Zumindest beim UDP Tests waren die Maximalergebnisse (96 MBit netto) sehr gut. Beim Einsatz eines VPNs raucht die Geschwindigkeit aber total ab. Das Maximum war bei einer AES256 Verschlüsselung mit 10 MBit herauszuholen. Warum beim UDP Test der Rückweg nur 0,1 MBit liefert, kann ich nicht beurteilen.

Die 7430 liefert beim reinen Routing/NAT Test starke Werte um die 95 MBit. Aber auch sie knackt beim VPN-Durchsatz Test stark ein. Maximal 15 MBit bei der Verwendung von AES256 waren drin.

Fazit

Gerne wird die FRITZ!Box im privaten als auch im semi-professionellen Umfeld nicht nur als Internet-Router, sondern auch als VPN-Gateway eingesetzt. Ungeachtet der Tatsache, dass man im Firmenumfeld sowieso nicht auf ein Privatprodukt setzen sollte, ist der nutzbare VPN-Durchsatz bei knapp 15 MBit/s teilweise deutlich unter den reinen Internetgeschwindigkeiten, die man heute durch VDSL und Glasfaser so bekommt. Daher sollte man sich gut überlegen, wo und wie man die FRITZ!Box dafür einsetzt.

Mangels Hardware konnte ich leider nicht noch das aktuelle Topmodell von AVM, die FRITZ!Box 7490, testen. Da dasVer- und Entschlüsseln der VPNs aber rein in Software/CPU passiert, lässt ein Blick auf Vergleichstabellen der CPUs der Geräte [1, 2, 3] leider nur erahnen, dass auch das Topmodell nur wenig besser sein dürfte, da die Geschwindkeit der CPU nur leicht angehoben wurde.

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.

(This post is very similar to this one in which I covered Juniper ScreenOS firewalls.)

I assume that there is already a VPN connection between two Palo Alto firewalls in place. If so, the steps to tunnel IPv6 through this VPN tunnel are quite easy. (Note that this is NOT a 6in4 tunnel! It is simply a forwarding of IPv6 packets through a common IPsec site-to-site VPN.)

Tunneling

I am using two PA-200 firewalls with PAN-OS 7.1.1. One firewall has a static IPv4 address, the other one is dynamic. I am routing a /60 through the tunnel to have a maximum of 16 subnets on the remote site. This is how the lab looks like:

The basic step is to enable IPv6 on the tunnel interfaces and to route the IPv6 traffic appropriately. Of course, all other interface configuration steps such as router advertisements as well as security policies must be configured, too.

Main Site

These are the configuration steps on the main site in order to route the IPv6 subnet through the tunnel. See the screenshot descriptions for more details:

Remote Site

Very similar: the remote site. Note the default IPv6 route through the tunnel:

Latency & Hop Count

After committing everything the traffic log shows some IPv6 connections, either from trust to vpn-s2s (on the remote site), or from vpn-s2s to untrust (on the main site):

It is interesting to see the IPv6 ping times from the remote site compared to the IPv4 ping times. Since the IPv6 connections must travel through the IPv4 VPN tunnel via the Internet before reaching the real destination, the RTT should be much higher than the IPv4 times. However, everything is relative. The ping times (IPv6 and IPv4) on my main site are both around 5-8 ms in the following example:

C:\Users\weberj>ping -4 www.insinuator.net

Ping wird ausgeführt für www.insinuator.net [62.159.96.203] mit 32 Bytes Daten:
Antwort von 62.159.96.203: Bytes=32 Zeit=8ms TTL=57
Antwort von 62.159.96.203: Bytes=32 Zeit=6ms TTL=57
Antwort von 62.159.96.203: Bytes=32 Zeit=8ms TTL=57
Antwort von 62.159.96.203: Bytes=32 Zeit=5ms TTL=57

Ping-Statistik für 62.159.96.203:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 5ms, Maximum = 8ms, Mittelwert = 6ms

C:\Users\weberj>
C:\Users\weberj>
C:\Users\weberj>ping -6 www.insinuator.net

Ping wird ausgeführt für www.insinuator.net [2003:60:4010:11b0::12] mit 32 Bytes Daten:
Antwort von 2003:60:4010:11b0::12: Zeit=5ms
Antwort von 2003:60:4010:11b0::12: Zeit=5ms
Antwort von 2003:60:4010:11b0::12: Zeit=5ms
Antwort von 2003:60:4010:11b0::12: Zeit=5ms

Ping-Statistik für 2003:60:4010:11b0::12:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 5ms, Maximum = 5ms, Mittelwert = 5ms

But since my remote site is a DSL connection with a slower latency at all, the IPv6 burden is not that high, as seen here. Both connections are around 30 ms:

C:\Users\Johannes Weber>ping -4 www.insinuator.net

Ping wird ausgeführt für www.insinuator.net [62.159.96.203] mit 32 Bytes Daten:
Antwort von 62.159.96.203: Bytes=32 Zeit=32ms TTL=54
Antwort von 62.159.96.203: Bytes=32 Zeit=31ms TTL=54
Antwort von 62.159.96.203: Bytes=32 Zeit=31ms TTL=54
Antwort von 62.159.96.203: Bytes=32 Zeit=31ms TTL=54

Ping-Statistik für 62.159.96.203:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 31ms, Maximum = 32ms, Mittelwert = 31ms

C:\Users\Johannes Weber>
C:\Users\Johannes Weber>
C:\Users\Johannes Weber>ping -6 www.insinuator.net

Ping wird ausgeführt für www.insinuator.net [2003:60:4010:11b0::12] mit 32 Bytes Daten:
Antwort von 2003:60:4010:11b0::12: Zeit=35ms
Antwort von 2003:60:4010:11b0::12: Zeit=29ms
Antwort von 2003:60:4010:11b0::12: Zeit=30ms
Antwort von 2003:60:4010:11b0::12: Zeit=29ms

Ping-Statistik für 2003:60:4010:11b0::12:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 29ms, Maximum = 35ms, Mittelwert = 30ms

That’s it.

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.

Lab

My lab consists of two PA-200 firewalls with PAN-OS 7.1.1 installed. They were plugged into a simple layer 2 switch. The two notebooks were booted with Knoppix 7.6.1 and used Iperf version 2.0.5.

I first tested the throughput with only routing and then built the VPN. After every test I changed the phase 2 parameters. The Iperf tests ran in both directions. Here are some configuration screenshots:

Of course I verified the correct IPsec algorithms after each change, such as here:

weberjoh@fd-wv-fw02> show vpn ipsec-sa tunnel VPN-Test

GwID/client IP  TnID   Peer-Address           Tunnel(Gateway)                                Algorithm          SPI(in)  SPI(out) life(Sec/KB)
--------------  ----   ------------           ---------------                                ---------          -------  -------- ------------
20              24     80.154.108.226         VPN-Test(VPN-Test)                             ESP/3DES/SHA1      9AA65C85 D49DF3F6 3481/0

Show IPSec SA: Total 8 tunnels found. 1 ipsec sa found.

Test Results

Here are the results, each Tx/Rx in Mbps:

And the raw values:

• Only routing: 937/934
• esp-3des-sha1-group2-1h: 198/228
• esp-aes128-sha1-group5-1h: 215/271
• esp-aes256-sha256-group14-1h: 205/254
• esp-aes256-sha512-group20-1h: 212/260

That is: All tests are around 200 Mbps. The Tx direction is always a bit slower, which might be a test failure. The AES algorithms are faster than the old 3DES cipher. This might be related to the fact that AES is made to be fast in software and in hardware.

Conclusion

Wow, these are really high values. The data sheet talks about 50 Mbps, even for the bigger PA-500 firewall. I don’t know why, but my test results are four times greater than the official notes. Ok, I can live with that.