Palo’s Mgmt-Intf is not usable with IPv6 anymore

Wow, that was unexpected: With PAN-OS 11.1 the out-of-band management interface of Palo Alto Networks firewalls doesn’t accept an IPv6 default route pointing to one of its own data interfaces anymore. That is: In most setups, you can’t use IPv6 for management purposes anymore. “Works as expected.” Wow. Really?

Setup

This is how we normally connect the management interface to one of the internal layer 3 interfaces/VLANs from the firewall itself (at least in small environments where the out-of-band management is not within its own dedicated infrastructure):

The default gateway for the management interface points to one of the IP addresses of a data interface of the same firewall. In my lab, the management interface settings look as follows:

Error

I upgraded a PA-440 from PAN-OS 11.0.3 to 11.1.1. After the reboot, the auto-commit was not able to succeed. It ended in an auto-commit loop. I did a “commit force” from the CLI which showed the following error:

After I changed the default gateway of the mgmt-interface (IPv6) to an unused IPv6 address, the commit succeeded. However, when changing it back to the correct default gateway (which is a layer 3 subinterface from the same firewall itself), the same error appears again.

Some notes:

  • I am using a logical router (not a virtual router). Hence I’m confused about this error since it reads “In virtual-router default: …”
  • This configuration was fully valid and running with PAN-OS 11.0.3 and previous versions for the last decade!
  • The IPv6 default gateway from the mgmt interface is the IPv6 global unicast address from ethernet1.3/21. Same for IPv4 where it’s still working.
  • I also tried to change the IPv6 default gateway address to the link-local address of ethernet1.3/21, which resulted in the same error.

Reply from PANW

Of course, I opened a support ticket with Palo Alto Networks. It turned out that this behaviour is already known and working as expected starting with PAN-OS 11.1. WHAT?

Root Cause:
============
Kernel doesn’t allow local IPv6 address as Gateway. So when we try add one of the DP interface IPv6 address as management interface IPv6 gateway, it throws an error “Error: Gateway can not be a local address.” So we shouldn’t support something that is not supported by the kernel. Hence decided to prevent user to configure the DP interface as management default gateway.

Fix:
===========
– This is functioning as designed from the PAN-OS version 11.1.0.

I also requested and got the bug ID, but since it is internal only, I won’t publish it here.

At least the engineering team was instructed to write documentation about this. Hahaha.

Some Notes

  • Isn’t it a real “out-of-band management” since the very beginning? If it were a real separate management plane, this would not happen, because the management and data plane would be *separate*. Hence it’s not the case. Ups.
  • To my mind, this setup (routing the management traffic through the firewall itself) is quite common if not the de facto standard. Why is Palo Alto Networks refusing this setup?
  • Isn’t Palo Alto Networks testing PAN-OS upgrades before releasing them enough? I would have expected this error to be noticed. I’m talking about the upgrade from PAN-OS 11.0 to 11.1. Either through a pre-check (before installing the upgrade) or at least through release notes.
  • Though Palo Alto Networks was a little behind concerning IPv6 completeness for the last years (e.g., DHCPv6-PD was introduced with PAN-OS 11.0 while other vendors had it for a couple of years), the quality of their implementation was always very good. But now they have introduced a big deal when it comes to IPv6. Bugs like this are not helping while deploying IPv6 at the customers’ sites.
  • Why is it still working with legacy IP? That is: Which “kernel” upgrade brought them to this error?
  • As workarounds, you must use “Interface Mgmt” profiles to access the firewall via HTTPS/SSH/SNMP/API on data interfaces rather than on the management interface.
  • Furthermore, you must rely on legacy IP for all other services such as DNS, NTP, syslog, authentication servers, etc. <– That’s exactly what was IPv6-only in my lab. D’oh!

Just as an example, this is how my NTP went dead (status: error, reachable: no):

Too bad.

R.I.P. IPv6-only at Palo Alto Networks firewalls. 😢

Soli Deo Gloria!

Photo by Jussara Paulo on Unsplash.

7 thoughts on “Palo’s Mgmt-Intf is not usable with IPv6 anymore

  1. That seems verty strange, not least given that Palo Alto Networks use the MGMT interface as default service route for all services, including internet based (updates, wildfire, dlp, you name it). So they must know that the MGMT network will require access and who would be better to provide a safe internet access, than the firewall itself?

    Great heads up though – I am just about to change my ISP and at the same time test a PA-415-5G, which require PAN-OS 11.1.0 (it reboot loops if upgraded beyond 11.1.0 and the cellular1/1 is active). I will be using IPv6, so I guess I have an issue too :-/

    Regards
    /Uffe

  2. Odd, I have justed pushed a config from Panorama to my PA-415-5G, using a DP interface as GW for management interface and I didn’t get any commit errors. I can connect to MGMT IP as well, but I connect from the MGMT network, not through the firewall it self. Running 11.1.0-h3. The firewall is not fully connected yet, so I can only perform limited testing.

    Your “IPv6 Address/Prefix Lenght” look a little strange in the picture – ending with :443? There should be a /64 and not a port number.

    1. Oh, sorry for the hint. I uploaded the wrong screenshot. Fixed it. Thanks. (Yes, I’m using the last hextet out of the IPv6 address as a hint of the service, which is 443 in this case. “dig pa-mgmt.weberlab.de aaaa”)

      I just tested it again with PAN-OS 11.1.2-h3 and it’s still exactly the same error. :( Are you sure that your commit succeeded? (I’ve not tested PAN-OS 11.1.0 explicitly, as I upgraded from 11.0.3 to 11.1.1.)

      1. But 443 in HEX is 1091 in decimal, so the last hextet ought to be 1BB ;-) Yes, commit succeeded flawlessly. I use the vrouter in PAN-OS, while you mention a “logical router” in your use case, but I’m uncertain of what you mean by that, so I can’t tell if it is significant. My MGMT interface is 2a05:f6c7:6633:1101::207 with a GW of 2a05:f6c7:6633:1101::1 and the VLAN1101 DP subnet is 2a05:f6c7:6633:1101::1/64.

      2. Interesting – just got this, after several successfull commits:
        In virtual-router default: Mgmt IPv6 GW 2a05:f6c7:6633:1101:0:0:0:1/128 is conflict with address 2a05:f6c7:6633:1101:0:0:0:1/64 on interface ae1.1101.

  3. I was planning to test today, what would happen if you put in a dynamic IPv6 and gateway for MGMT interface, but I asked a collegue if he had encountered this issue and he already had a fix. Add the IPv6 address as Static and the Gateway a Dynamic. It works fine for me – I can ping the management IP address from my montoring server on another subnet, through the firewall.

    1. And then it didn’t work again – no clue as to. The interface is set to announce router, so it ought to announce the LLA of the interface as gateway. It seems as if the MGMT interface doesn’t pick it up, tough.

      However, the LLA is in the show interface:
      urb@pa-415-5g> show interface ae1.1101

      ——————————————————————————–
      Name: ae1.1101, ID: 258, 802.1q tag: 1101
      Operation mode: layer3
      Virtual router default
      Interface MTU 1500
      Interface IP address: 192.168.101.1/24
      Interface IPv6 address: fe80::3efa:30ff:fe7d:3330/64
      2a05:f6c7:6633:1101::1/64

      Now I have added fe80::3efa:30ff:fe7d:3330 as my Default IPv6 Gateway Address and I can ping from my monitor subnet to the MGMT:
      urb@monitor.twe.net:~$ ping 2a05:f6c7:6633:1101::207
      PING6(56=40+8+8 bytes) 2a05:f6c7:6633:1052::c –> 2a05:f6c7:6633:1101::207
      16 bytes from 2a05:f6c7:6633:1101::207, icmp_seq=0 hlim=63 time=0.834 ms
      16 bytes from 2a05:f6c7:6633:1101::207, icmp_seq=1 hlim=63 time=0.705 ms

      As your WP themes apparently doesn’t allow forved line breaks, this i sprobably quite ureadable :-)

Leave a Reply

Your email address will not be published. Required fields are marked *