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:
Tested environments: PA-220 with PAN-OS 10.2.4-h2 and 10.2.5, as well as PA-440 with PAN-OS 11.0.2-h2.
I basically stumbled upon this problem as I played around with some traceroutes:
weberjoh@nb15-lx:~$ traceroute -6 lx2.weberlab.de
traceroute to lx2.weberlab.de (2001:470:1f0b:16b0::a36:22), 30 hops max, 80 byte packets
2 * * *
3 * * *
4 * * *
5 port-channel12.core2.fra1.he.net (2001:470:0:63d::1) 3.155 ms 3.590 ms *
6 tserv1.fra1.he.net (2001:470:0:69::2) 46.521 ms 49.557 ms 52.595 ms
7 tunnel525322-pt.tunnel.tserv6.fra1.ipv6.he.net (2001:470:1f0a:16b0::2) 124.070 ms 122.339 ms 121.901 ms
8 2001:470:1f0b:16b0::a36:22 (2001:470:1f0b:16b0::a36:22) 80.968 ms 77.495 ms 74.469 ms
In Wireshark, this looks as follows:
Later on, I discovered the same behaviour when a security policy’s action is set to “Drop” along with “Send ICMP Unreachable”, e.g. here:
This looks as follows in Wireshark (different ICMPv6 type, but the same wrong address):
RFC 4443 “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification” defines how the source address of an originating ICMPv6 packet MUST look like:
Two more notes:
- This only happens with IPv6. For legacy IP, the correct data interface IPv4 address is chosen as the source address.
- This only appears on VLAN interfaces, but not on “normal” Layer 3 interfaces. <- This is interesting because some years ago I found another IPv6 bug which was related to a VLAN interface as well. To me, this seems like the IPv6 routines for different types of interfaces on PAN-OS are not exactly the same.
On a mere Layer 3 interfaces those ICMPv6 packets are sourced correctly:
PAN Ticket -> Bug
In October 2022, I created a ticket at the PAN support, telling them about this bug. Luckily, I was able to convince the ticket owner that this has to be fixed since it is clearly a violation of the Internet standards. (To be fair, I also told them that I don’t believe that this is a big thing nor security-related.) The bug got the bug ID PAN-214336. After some months, I got an update from the engineering team, saying that this should be fixed with PAN-OS 10.2.5. Unfortunately, this wasn’t the case. Neither is this bug listed in the release notes nor is it actually fixed with PAN-OS 10.2.5, as I tested it again. Furthermore, it is present in the PAN-OS 11.x major versions as well.
Hopefully, it will get fixed someday. At least, you guys can google it now. :)
Soli Deo Gloria.