During my IPv6 classes, I discovered a (minor) bug at the NGFW from Palo Alto Networks: ICMPv6 error messages, such as “time exceeded” (type 3) as a reply of traceroute, or “destination unreachable” (type 1) as a reply of a drop policy, are not correctly sourced from the IPv6 address of the data interface itself, but from the unspecified address “::”. Here are some details:
An analysis of some falsified leap second warnings that appeared in November 2021 on public NTP servers out of the NTP Pool Project.
As we have just set up a TLS capable syslog server, let’s configure a Palo Alto Networks firewall to send syslog messages via an encrypted channel. While it was quite straightforward to configure I ran into a couple of (unresolved) problems as I added and deleted some syslog servers and their certificates. Uhm.
The NTP Pool is a volunteer organization that provides time synchronization service to hundreds of millions of computers worldwide. A typical client might query a particular NTP Pool server ~10-60 times/hour. Wikipedia lists some abusive clients that far exceeded the normal rate. This wastes NTP server resources, may interfere with other clients, and can trigger DDoS protections. In late 2019, a software update made some FortiGate firewalls very unfriendly to the NTP Pool.
Infoblox offers a nice product which completely serves the DHCP/DNS/IPAM aka DDI area. I really love it. Especially the centralized management aka Grid works quite stable and is easy to use (though the GUI looks a bit outdated).
However, sometimes I am little beyond the daily business and labbing with next-generation features such as #IPv6, #DNSSEC, #NTP authentication, CAA, SSHFP, and so on. Not everything within these topics is included, hence a couple of feature requests. Just a living list from my perspective.
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:
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:
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 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.
A few months ago I found a small bug in PAN-OS, 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).
While testing with the new release of Hydra against my own FTP server from FileZilla, I recognized that the autoban feature from FileZilla does not work for IPv6 connections. If there are multiple failed login attempts from an IPv4 address, FileZilla Server correctly blocks that IP. That is: Hydra stops testing passwords since it is not able to connect to the server anymore. However, when using IPv6, the FileZilla server generates the same error message (“421 Temporarily banned for too many failed login attempts”), but new connections from the same IPv6 address are still possible.
Here are my test results:
Last year, I posted the following bug report on the IPv6 hackers mailing list, but nobody ever responded. I also sent it to Microsoft, but heart no response either. Since I am owning this blog since a few days, I will post it here, too:
I am testing with the THC-IPV6 Toolkit from van Hauser and noticed that Windows 7 adds and deletes several neighbor cache entries even on interfaces which are not connected. It further adds and deletes complete network interface cards from the neighbor cache. I would like to know if this is a feature or a bug.