Quantcast
Channel: Network – Weberblog.net
Viewing all articles
Browse latest Browse all 253

Palo Alto IPv4 vs. IPv6 Performance Speedtests

$
0
0
Palo IPv4 vs IPv6 featured image

After I have done some speedtests on the FortiGate firewall I was interested in doing the same tests on a Palo Alto. That is: What are the throughput differences of IPv4 vs. IPv6, measured with and without security profiles, i.e., with and without threat prevention.

It turned out that the throughput is much higher than the official information from Palo Alto. Furthermore, I was not able to test the threat prevention at all, because non of my traffic (Iperf and mere HTTP) went through the antivirus engines. I have to test this again. However, here are the measured values so far:

Laboratory & Scenarios

I had a single PA-200 with PAN-OS 7.1.1 installed. The two test notebooks ran Knoppix 7.6.1 and Iperf version 2.0.5. This time I only used the TCP test. For the HTTP tests I used an Apache2 webserver on the one side and wget on the other side.

I tested the following scenarios, all of them routed through the Palo Alto:

  1. Iperf, single policy rule, NO security profiles, both directions. This was recognized as “unknown-tcp” though the application “iperf” exists. (Refer to Applipedia.)
  2. Iperf, with security profiles, still recognized as unknown-tcp, both directions.
  3. Iperf, with security profiles and app-override, now displayed as “iperf”, both directions.
  4. HTTP, with security profiles, recognized as “web-browsing”, only server to client direction, but with enabled server response inspection.

Here are a few screenshots of the policies and the traffic log:

Security Policy without Security Profiles Security Policy WITH Security Profiles Security Policy WITH Security Profiles Traffic Log without Security Profiles unknown-tcp Traffic Log WITH Security Profiles http wget

And a listing from one wget HTTP test:

root@Microknoppix:~# wget http://[2003:51:6012:171:221:70ff:fee9:bb47]/1G-file
--2016-05-06 11:14:49--  http://[2003:51:6012:171:221:70ff:fee9:bb47]/1G-file
Verbindungsaufbau zu [2003:51:6012:171:221:70ff:fee9:bb47]:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1048576069 (1000M)
Wird in »»1G-file.1«« gespeichert.

1G-file.1                     100%[=================================================>]   1000M  88,1MB/s    in 11s

2016-05-06 11:15:01 (87,7 MB/s) - »»1G-file.1«« gespeichert [1048576069/1048576069]

Results

These are the test results:

All measured values are almost around 930 Mbps, except the Apache/wget/HTTP traffic. I suppose that this comes from other parameters such as the Apache server, the local file reading/writing, or wget.

For the sake of completeness, these are the raw values, each with Tx/Rx in Mbps:

  • Iperf without security profiles, unknown-tcp: IPv4 = 940/934, IPv6 = 926/921
  • Iperf with security profiles, unknown-tcp: IPv4 = 939/934, IPv6 = 926/921
  • Iperf with security profiles and app override -> iperf: IPv4 = 942/936, IPv6 = 929/923
  • HTTP with security profiles, web-browsing, single direction: IPv4 = 774, IPv6 = 704

Conclusion

Ok, this is really strange! Palo Alto lists a firewall throughput for the PA-200 of 100 Mbps and a threat prevention throughput of 50 Mbps. My tested results are way beyond that.

Much better compared to the results from the FortiGate are the “v4 vs. v6” differences. Both protocols are almost at the same speed.

Concerning the security profiles: As long as the application is not recognized correctly (and only shown as unknown-tcp), the threat prevention will not work. That’s ok. Similar to the app override, refer to this PAN documentation: “An application override with a custom application will prevent the session from being processed by the App-ID engine, which is a Layer-7 inspection.” But why is the threat prevention not working for the web-browsing traffic? The throughput should dramatically decrease when the whole traffic is scanned for viruses, etc., shouldn’t it?


Viewing all articles
Browse latest Browse all 253

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>