==
Home » Uncategories » Palo Alto Information

Palo Alto Information



Palo Alto VPN Speedtests featured image

Palo Alto VPN Speedtests

Bandwidth/Delay, IPsec/VPN, Palo Alto Networks, , , , ,

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.
Palo Alto VPN Speedtests Labor
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:

Test Results

Here are the results, each Tx/Rx in Mbps:
Palo Alto VPN SpeedtestsNo VPN TxNo VPN Rx3des-sha1-group2 Tx3des-sha1-group2 Rxaes128-sha1-group5Txaes128-sha1-group5Rxaes256-sha256-group14 Txaes256-sha256-group14 Rxaes256-sha512-group20 Txaes256-sha512-group20 Rx02505007501000MBit/s
foobarNo VPN TxNo VPN Rx3des-sha1-group2 Tx3des-sha1-group2 Rxaes128-sha1-group5 Txaes128-sha1-group5 Rxaes256-sha256-group14 Txaes256-sha256-group14 Rxaes256-sha512-group20 Txaes256-sha512-group20 Rx
blubb937934198228215271205254212260
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. 😉

Palo IPv4 vs IPv6 featured image

Palo Alto IPv4 vs. IPv6 Performance Speedtests

Bandwidth/Delay, IPv6, Palo Alto Networks, , , , , , ,

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:
And a listing from one wget HTTP test:

Results

These are the test results:

Palo Alto IPv4 vs. IPv6 SpeedtestsIperf w/o sec TxIperf w/o sec RxIperf w/ sec TxIperf w/ sec RxIperf w/ sec and appoverride TxIperf w/ sec and appoverride RxHTTP w/ sec RxIPv4IPv602505007501000MBit/s
IP-VersionIperf w/o sec TxIperf w/o sec RxIperf w/ sec TxIperf w/ sec RxIperf w/ sec and app override TxIperf w/ sec and app override RxHTTP w/ sec Rx
IPv4940934939934942936774
IPv6926921926921929923704

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?


Palo Alto disk space 01 error

Palo Alto Software Download Failure

Palo Alto Networks, , ,

I had an error on my PA-200 with PAN-OS 7.0.5 while trying to download a new firmware version. “Error: There is not enough free disk space to complete the desired operation. […]”. Even the tips to delete older software, dynamic updates, etc., and to use the “set max-num-images count” command did not lead to a successful download.
Finally, the TAC support could solve the problem via root access to the Palo Alto firewall and by manually moving data files…

This was the disk space on the firewall before the TAC support corrected it (note the 5th line with 92 % usage):
And on my monitoring server I could see that the management config partition increased its usage a few weeks ago:
Palo Alto disk space 03 Management Config Partition
The supporter now used the  debug tac-login challenge  and  debug tac-login response  commands to gain root access on my PA-200. (Interesting…) He said that the problem is due to not deleted AV- and content-packages. He then did the following steps:
  1. He navigated to the folder in which the AV and content packages reside.
  2. He moved the “newav” folder to another partition. Now there was enough disk space on the current partition.
  3. Via the GUI, he upgraded the content packages. This worked and PAN-OS correctly deleted the temporary content files.
  4. He then moved back the AV files (newav) to the original partition
  5. and upgraded the AV packages appropriately. This worked, too, and PAN-OS correctly deleted the temporary AV files, too.
Now the usage of /dev/sda5, mounted on /opt/pancfg, was about 73 %:
This is the daily graph of the management config partition which shows the decrease of the space usage during the support call:
Palo Alto disk space 04 Management Config Partition during Support Case
After this procedure, I was able to update man PAN-OS to a newer version. Thank you. And hopefully this bug will be fixed in an upcoming version! (Bug number 94106.)

[UPDATE]

After I ran into this issue one more time, I received an answer from the Palo Alto Support with the following link: https://live.paloaltonetworks.com/t5/Management-Articles/How-to-Free-Up-Disk-Space-in-PAN-OS-5-0/ta-p/63151. And in fact, after deleting some files etc., the download of new dynamic updates worked again. This link was also sent to me by the support, but I did not need it here: https://live.paloaltonetworks.com/t5/Management-Articles/How-and-When-to-Clear-Disk-Space-on-the-Palo-Alto-Networks/ta-p/55736.
These are the commands I used in my case. The usage of /opt/pancfg decreased from 92% to 86%:
My monitoring system shows the decrease of the disk usage as well as a successful installation of antivirus patterns at 5 am:
Palo Alto disk space 06 after manually deleting one day





IPv6 through IPv4 VPN Tunnel

IPv6 through IPv4 VPN Tunnel with Palo Alto

IPsec/VPN, IPv6, Palo Alto Networks, Routing, , , ,

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:
IPv6 through IPv4 VPN Tunnel Palo Alto - Lab
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:

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:

That’s it.




Android Palo VPN featured image

Palo Alto Remote Access VPN for Android

Android, IPsec/VPN, Palo Alto Networks, , , ,

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:
DNS Proxy Featured Image

Palo Alto: DNS Proxy for Management Services

DNS, Palo Alto Networks, , ,

The Palo Alto firewall has a feature called DNS Proxy. Normally it is used for data plane interfaces so that clients can use the interfaces of the Palo for its recursive DNS server. Furthermore, this DNS Proxy Object can be used for the DNS services of the management plane, specified under Device -> Setup -> Services. However, there was a bug in PAN-OS that did not process the proxy rules and static entries when a DNS proxy object was used in the management plane. This bug was fixed in PAN-OS 6.0.0. I tested it in my lab with PAN-OS 6.1.0 running. Here are the successful results.

The fixed bug in version 6.0.0 was bug ID 41472: “When a DNS Proxy object was configured with static entries, hostnames assigned to the DNS Proxy were resolved as expected to the IP addresses listed on the Static Entries tab (Network > DNS Proxy) . However, when setting the DNS Proxy Object as the DNS Service on the Device > Setup > Services dialog, all DNS queries from the management interface ignored the defined static entries.”

DNS Proxy

I added a DNS proxy called “Google” with their two public DNS servers, as well as a few proxy rules to other DNS servers and static entries. This proxy object was then referenced for the management services as a “DNS Proxy Object”:

Tests

After a commit, I pinged a few hosts from the management plane. The first one should use the default DNS server, while the three following requests should use the proxy rules. The last object was the static entry in the DNS proxy.

Since the default route of the management interface points through one of the data interfaces of the Palo Alto, I could easily do a packet capture on the Palo itself. It correctly revealed the three different DNS servers for the requests. Of course, the request to the static entry is not shown since it did not trigger a DNS request to a server.
DNS-Proxy Test Wireshark

Works as Expected

The tests showed that the function of a DNS proxy for the management services works as expected. Not only the default DNS servers, but also the proxy rules and static entries are used through the management plane.
Note that the following scenarios do NOT work:
  • Pre PAN-OS 6.x, the DNS Proxy object used in the management services sent all requests to the primary and secondary DNS servers but NOT to the proxy rules. The static entries were not used, too.
  • It is not possible to set a “DNS Server” in the management services to the IP address of a data interface of the Palo Alto itself. This won’t work since the Palo uses some kind of internal path when sending packets to an own data interface. This means, if a DNS Proxy object should be used, it must be selected as a “DNS Proxy Object” and not as an entry of “DNS Servers”.
Palo Alto Save-Load Config 2

Palo Alto: Save & Load Config through CLI

Palo Alto Networks, , , ,
When working with Cisco devices anyone knows that the output of a “show running-config” on one device can be used to completely configure a new device. On a Palo Alto Networks firewall, this is not that obvious. There are several commands that must be used to achieve the same.
However, I tested this procedure a few times and it did NOT work. 🙁 So, the short version is: If you want to replace a Palo Alto firewall, move your configuration files (xml) through the GUI or tftp/scp. But do not use the mere CLI.

The most common way to save a Palo Alto config is via the GUI at Device -> Setup -> Operations ->  Export xyz. And even on the CLI, the running-config can be transferred via scp or tftp, such as scp export configuration from running-config.xml to username@host:path . This configuration file can be loaded into a new device, again, via the GUI (Import) or the CLI ( scp import configuration from username@host:path ).

Save

However, to save the complete configuration in the “set” format, the following CLI commands must be used. The first one is used to output the configuration in single “set” lines (instead of XML blocks), and the second one switches the output to not stop after a few lines on the terminal. To capture long lines without a “carriage return”, the terminal width should be adjusted to the maximum of 500. Then, the “configure” command enters the configuration mode, while the “show” command displays the whole running configuration.

And Load

To load the config into a new device, a few commands must be used before. At first, the terminal width should be adjusted again. Furthermore, the scripting-mode must be enabled in order to send a bulk of CLI commands without an error. The reason for that is, that several objects are referenced in the configuration before they are added to the device. E.g., the set commands for the “security rules” are before the set commands for the “application groups”. That is, an application group is used by a security rule before it is added to the config. 🙁
Finally, the whole bunch of set commands from above can be pasted into the CLI session.

Errors, Errors, Errors

I wanted to load a complete configuration from a firewall to another. (Both firewalls were of the same type, OS version (6.0.x) and license.) I used the console port on the device. But even with the aforementioned commands that should make this procedure possible, I got only errors, such as: “Invalid syntax.” or “Unknown command: …”.
Furthermore, the terminal session looked like a complete chaos:

Conclusion

Only use the complete XML-based configuration files and not the set commands!

Palo Alto IPv6 MGT interface reachable

Minor Palo Alto Bug concerning IPv6 MGT

IPv6, Palo Alto Networks, , , , ,

A few month ago I found a small bug in PANOS, the operating system from Palo Alto Networks. It is related to an IPv6 enabled management interface. The MGT address was not reachable when the firewall operates in layer 2 mode, that is, had layer 2 interfaces along with VLANs. Luckily, this bug is fixed with the new software version 6.1.2 which was released this week (bug ID 67719).
Following are a few listings that show the incomplete handling of the IPv6 neighbor cache of the MGT interface in the old version (pre 6.1.2).

I was using the layer 2 mode for some switch tests about STP. During these tests I noticed that I was not able to connect to the MGT interface via IPv6 anymore.
The Palo Alto in my lab has a VLAN interface (vlan.120) and the corresponding VLAN on a layer 2 subinterface. The management port is plugged into a switch in the same VLAN. The IPv6 address on the MGT interface is 2003:51:6012:120::2/64 .

Bug

For example, when trying to ping or to ssh to the MGT interface from another machine …
… the neighbor cache did not show the MGT IPv6 address:

However, I was able to ping from that MGT interface IPv6 address. Interestingly, the neighbor cache revealed the ::2 address, but only with the status “PROBE” and only for a very few seconds:

The traffic log on the Palo Alto shows that incoming connections did not succeed, while outgoing connections did:
Palo Alto IPv6 MGMT interface pings

Fixed in 6.1.2

with bug ID 67719: “The management interface was not receiving IPv6 connections for traffic from the dataplane when the firewall was in Layer 2 mode. An update was made to the MAC address learning process so that the Management interface receives IPv6 traffic from the dataplane when the firewall is in Layer 2 mode.”
Now I can ping to the IPv6 MGT address:
And the neighbor cache correctly shows the REACHABLE/STALE neighbor:
OSPFv3 Lab Featured Image

OSPFv3 for IPv6 Lab: Cisco, Fortinet, Juniper, Palo Alto, Quagga

Cisco Systems, Fortinet, IPv6, Juniper Networks, Palo Alto Networks, Quagga, Routing, , , , , , , , , , ,

Similar to my test lab for OSPFv2, I am testing OSPFv3 for IPv6 with the following devices: Cisco ASA, Cisco Router, Fortinet FortiGate, Juniper SSG, Palo Alto, and Quagga Router. I am showing my lab network diagram and the configuration commands/screenshots for all devices. Furthermore, I am listing some basic troubleshooting commands. In the last section, I provide a Tcpdump/Wireshark capture of an initial OSPFv3 run.
I am not going into deep details of OSPFv3 at all. But this lab should give basic hints/examples for configuring OSPFv3 for all of the listed devices.

Lab

This is my test lab. All devices are directly connected via a layer 2 switch:
OSPFv3 Lab

General Information

  • Everything takes place in area 0.0.0.0 (backbone area)
  • Juniper SSG should be the DR: interface priority set to 100.
  • Palo Alto should be the BDR: interface priority set to 50.
  • Router-ID is always set manually according to my IPv4 sheme: 172.16.1.x, where x = the interface-ID from the IPv6 addresses (from ::1 to ::6).
  • Cost for the interfaces as seen in the figure.
  • Passive-interface on all user/access interfaces.
  • Redistribution of the remote access VPN clients on the Cisco ASA (AnyConnect).
  • No authentication is used .
The following devices are in alphabetic order. Beneath each screenshot is a detailed description of the the configuration that is shown.
During the tests, a single Cisco AnyConnect client was connected and therefore redistributed with a /128 IPv6 address prefix. The Quagga router was added to this lab after most of the listings were saved. That is: The Quagga router (172.16.1.8) is not shown on any other firewalls/routers.

Cisco ASA

The Cisco ASA 5505 is running version 9.2(4). Following are the configuration and monitoring screenshots:
This are the relevant CLI commands for the OSPFv3 config:
While this CLI commands can be used to show the OPSFv3 runtime values:

Cisco Router

I am running a Cisco 2811 router with version 15.1(4)M9. The configuration commands are the following: (Just for fun I set the OSPF process to “17”.)
And the show commands:

https://blog.webernetz.net/2015/09/14/ospfv3-for-ipv6-lab-cisco-fortinet-juniper-palo-alto/






Admin

Pro Teknologi dibuat pada 22 Februari 2017. Blog ini adalah harapan saya agar dapat membagi manfaat kepada orang lain,berupa tips-tips Seputar Blog,Internet,Komputer,dan Info-Info Menarik lainnya.

0 Response to "Palo Alto Information"

Post a Comment

Subscribe to: Post Comments (Atom)