For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blog post for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighbouring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
Continue reading Basic MP-BGP Lab: Cisco Router, Palo Alto, Fortinet
There are two methods of site-to-site VPN tunnels: route-based and policy-based. While some of you may already be familiar with this, some may have never heard of it. Some firewalls only implement one of these types, so you probably don’t have a chance to configure the other one anyway. Too bad since route-based VPNs have many advantages over policy-based ones which I will highlight here.
I had many situations in which network admins did not know the differences between those two methods and simply configured “some kind of” VPN tunnel regardless of any methodology. In this blogpost I am explaining the structural differences between them along with screenshots of common firewalls. I am explaining all the advantages of route-based VPNs and listing a table comparing some firewalls regarding their VPN features.
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
Continue reading File Blocking Shootout – Palo Alto vs. Fortinet
I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?
Just a quick note concerning the session sync on a Palo Alto Networks firewall cluster: Don’t trust the green HA2 bubble on the HA widget since it is always “Up” as long as the HA interface is up. It does NOT indicate whether the session sync is working or not. You MUST verify the session count on the passive unit to be sure. Here are some details:
I am using an almost hidden FTP server in my DMZ behind a Palo Alto Networks firewall. FTP is only allowed from a few static IP addresses, hence no brute-force attacks on my server. Furthermore, I have an “allow ping and traceroute from any to DMZ” policy since ping is no security flaw but really helpful while troubleshooting.
Now, here comes the point: My FTP server logfile showed dozens of connections from many different IP addresses from the Internet. WHAT? For the first moment I was really shocked. Have I accidentally exposed my FTP server to the Internet? Here is what happened:
Continue reading Palo Alto Application: First Packets Will Pass!
Until now I generated all SSHFP resource records on the SSH destination server itself via ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third-party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
And one more IPsec VPN post, again between the Palo Alto Networks firewall and a Fortinet FortiGate, again over IPv6 but this time with IKEv2. It was no problem at all to change from IKEv1 to IKEv2 for this already configured VPN connection between the two different firewall vendors. Hence I am only showing the differences within the configuration and some listings from common CLI outputs for both firewalls.
Continue reading IKEv2 IPsec VPN Tunnel Palo Alto <-> FortiGate
Towards the global IPv6-only strategy ;) VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP.
While it was quite easy to bring the tunnel “up”, I had some problems tunneling both Internet Protocols over the single phase 2 session. The reason was some kind of differences within the IPsec tunnel handling between those two firewall vendors. Here are the details along with more than 20 screenshots and some CLI listings.
Continue reading IPv6 IPsec VPN Tunnel Palo Alto <-> FortiGate
With PAN-OS version 8.0 Palo Alto Networks introduced another IPv6 feature, namely “NDP Monitoring for Fast Device Location“. It basically adds a few information to the existing neighbor cache such as the User-ID (if present) and a “last reported” timestamp. That is: the admin has a new reporting window within the Palo Alto GUI that shows the reported IPv6 addresses along with its MAC addresses. This is really helpful for two reasons: 1) a single IPv6 node can have multiple IPv6 addresses which makes it much more difficult to track them back to the MAC address and 2) if SLAAC is used you now have a central point where you can look up the MAC-IPv6 bindings (comparable to the DHCP server lease for legacy IPv4).
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how Windows and Linux react to it.
I want to talk about a fun fact concerning my blog statistics: Since a few years I have some “CLI troubleshooting commands” posts on my blog – one for the Palo Alto Networks firewall and another for the FortiGate firewall from Fortinet. If you are searching on Google for something like “palo alto cli commands” or “fortigate troubleshooting cli” my blog is always listed amongst the first 2-4 results.
But for some reasons the article for Fortinet has much more hits. I don’t know why but I have two different ideas. What do you think?
Since PAN-OS version 6.1 the Palo Alto Networks firewall supports LACP, the Link Aggregation Control Protocol which bundles physical links to a logical channel. Palo Alto calls it “Aggregate Interface Group” while Cisco calls it EtherChannel or Channel Group. I configured LACP for two ports connected from a Palo Alto firewall to a Cisco switch. Following are the configuration steps for both devices as well as some show commands.
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.