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 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).
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.