I just configured LLDP, the Link Layer Discovery Protocol, on a Palo Alto Networks firewall. What I really like about those firewalls is the completeness of configuration capabilities while the possibility to use it easily. Everything can be done via the GUI, even the view of neighbors/peers. Per default, only a few TLVs are sent by the Palo, but this can be extended by using LLDP profiles.
Following are a few configuration screenshots from the Palo as well as the config and show commands from a Cisco switch.
Continue reading Palo Alto LLDP Neighbors
I migrated an old Juniper SSG ScreenOS firewall to a Palo Alto Networks firewall. While almost everything worked great with the Palo (of course with much more functionalities) I came across one case in which a connection did NOT work due to a bug on the Palo side. I investigated this bug with the support team from Palo Alto Networks and it turned out that it “works as designed”. Hm, I was not happy with this since I still don’t understand the design principle behind it.
However, it was a specific and not business critical case: One Palo Alto firewall with two ISP connections using a destination network address translation (DNAT, an old IPv4 problem) and policy based forwarding (PBF) with the same destination ports. Following are some more details:
Continue reading Palo Alto PBF Problem
This is a cool and easy to use (security) feature from Palo Alto Networks firewalls: The External Dynamic Lists which can be used with some (free) 3rd party IP lists to block malicious incoming IP connections. In my case I am using two free IP lists to deny any connection from these sources coming into my network/DMZ. I am showing the configuration of such lists on the Palo Alto as well as some stats about it.
Continue reading Palo Alto External Dynamic IP Lists
I wanted to configure a weekly email report on a Palo Alto Networks firewall. “Yes, no problem”, I thought. Well, it was absolutely not that easy. ;(
While the PAN firewalls have a great GUI and a good design at all they lack an easy-to-use email reporting function, especially when compared to the FortiGate firewalls which have a great local report feature. –> If you want some stats on a weekly basis you must configure it completely from scratch. Unluckily this is not that easy since you must pass several steps for that. Therefore, I drew an outline of the Palo Alto reporting stages to have an overview of them.
Continue reading Palo Alto Reporting
Another great tool from Babak Farrokhi is dnstraceroute. It is part of the DNSDiag toolkit from which I already showed the dnsping feature. With dnstraceroute you can verify whether a DNS request is indeed answered by the correct DNS server destination or whether a man-in-the-middle has spoofed/hijacked the DNS reply. It works by using the traceroute trick by incrementing the TTL value within the IP header from 1 to 30.
Beside detecting malicious DNS spoofing attacks, it can also be used to verify security features such as DNS sinkholing. I am showing the usage as well as a test case for verifying a sinkhole feature.
Continue reading Detect DNS Spoofing: dnstraceroute
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.
Continue reading Palo Alto DNS Proxy Rule for Reverse DNS
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:
Continue reading Palo Alto FQDN Objects
This blog post is about using NetFlow for sending network traffic statistics to an nProbe collector which forwards the flows to the network analyzer ntopng. It refers to my blog post about installing ntopng on a Linux machine. I am sending the NetFlow packets from a Palo Alto Networks firewall.
My current ntopng installation uses a dedicated monitoring ethernet port (mirror port) in order to “see” everything that happens in that net. This has the major disadvantage that it only gets packets from directly connected layer 2 networks and vlans. NetFlow on the other hand can be used to send traffic statistics from different locations to a NetFlow flow collector, in this case to the tool nProbe. This single flow collector can receive flows from different subnets and routers/firewalls and even VPN tunnel interfaces, etc. However, it turned out that the “real-time” functionalities of NetFlow are limited since it only refreshes flows every few seconds/bytes, but does not give a real-time look at the network. It should be used only for statistics but not for real-time troubleshooting.
Continue reading Using NetFlow with nProbe for ntopng
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.
Continue reading Palo Alto VPN Speedtests
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:
Continue reading Palo Alto IPv4 vs. IPv6 Performance Speedtests
Since almost two years I am running a RIPE Atlas Probe in my server room. It resides in an own security zone on a Palo Alto firewall (which also powers the probe via its USB port :)). With this post I publish a few traffic statistics about the RIPE Atlas Probe.
Continue reading RIPE Atlas Probe Stats
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…
Continue reading Palo Alto Software Download Failure
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.
Continue reading IPv6 through IPv4 VPN Tunnel with Palo Alto
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.
Continue reading Where to terminate Site-to-Site VPN Tunnels?
Since a few weeks I am using Tufin SecureTrack in my lab. A product which analyzes firewall policies about their usage and their changes by administrators (and much more). Therefore, the first step is to connect the firewalls to SecureTrack in two directions: SSH from SecureTrack to the device to analyze the configuration, as well as Syslog from the device to SecureTrack to real-time monitor the policy usage.
This blog post shows the adding of the following firewalls into Tufin: Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, and Palo Alto PA.
Continue reading Tufin SecureTrack: Adding Devices