I am using the DNS Proxy on a Palo Alto Networks firewall for some user subnets. Beside the default/primary DNS server it can be configured with proxy rules (sometimes called conditional forwarding) which I am using for reverse DNS lookups, i.e., PTR records, that are answered by a BIND DNS server. While it is easy and well-known to configure the legacy IP (IPv4) reverse records, the IPv6 ones are slightly more difficult. Fortunately there are some good tools on the Internet to help reversing IPv6 addresses.
While I tested the FQDN objects with a Palo Alto Networks firewall, I ran into some strange behaviours which I could not reproduce, but have documented them. I furthermore tested the usage of FQDN objects with more than 32 IP addresses, which are the maximum that are supported due to the official Palo Alto documentation. Here we go:
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.
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:
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…
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.
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.
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.
This guide is a little bit different to my other Policy Based Forwarding blog post because it uses different virtual routers for both ISP connections. This is quite common to have a distinct default route for both providers. So, in order to route certain traffic, e.g., http/https, to another ISP connection, policy based forwarding is used.
Beside the HA1 and HA2 interfaces on a Palo Alto Networks firewall, there are the HA1/HA2 Backup and Heartbeat Backup options. I was a bit confused while reading the documentation of the high availability instructions since it did not clearly specify when and where to use the dedicated management port for what kind of “backup”.
Basically, it should read that there are two different ways on how to use the dedicated management for a HA Backup: the heartbeat backup OR the HA1 backup.
Since IPv6 gets more and more important, I am using it by default on all my test firewalls, which of course support IPv6. However, when comparing the different functions and administration capabilities, they vary significantly.
Here comes my short evaluation of the IPv6 functions on the following four firewalls: Cisco ASA, Fortinet FortiGate, Juniper SSG, and Palo Alto.
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.
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.
Another fixed issue in the just released PANOS version 6.1.2 from Palo Alto Networks is bug ID 71321: “Removed support for SSL 3.0 from the GlobalProtect gateway, GlobalProtect portal, and Captive Portal due to CVE-2014-3566 (POODLE).” I scanned my lab unit before (6.1.1) and after the OS upgrade (6.1.2) and here are the results.
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).