Limitations of Network Packet Broker
Focus
Focus

Limitations of Network Packet Broker

Table of Contents
End-of-Life (EoL)

Limitations of Network Packet Broker

Most Palo Alto Networks platforms support Network Packet Broker, but a few do not and a few have some limits:
  • Support is not available in Prisma Access or in NSX.
  • AWS, Azure, and GCP only support routed layer 3 security chains.
Network Packet Broker has a few limitations on Panorama for managed firewalls and a few usage limitations. On Panorama:
  • If you push Network Packet Broker licenses to managed firewalls, you must reboot the firewalls for the licenses and the associated user interface elements to be installed.
  • You cannot create a Packet Broker profile in a Shared context because you configure specific interfaces in the Packet Broker profile.
  • Different Device Groups cannot share the same Packet Broker profiles.
  • Panorama cannot push a Network Packet Broker configuration (Network Packet Broker policy rules and profiles) to a Device Group that contains firewalls which run a PAN-OS version older than 10.1.
    If you want to use Network Packet Broker in a Device Group that contains firewalls on multiple PAN-OS versions and some of those firewalls run a PAN-OS version older than 10.1, then you must either upgrade the pre-11.0 firewalls to PAN-OS 11.0 or remove the pre-11.0 firewalls from the Device Group before you push the Network Packet Broker configuration.
    You can use Panorama to push a Packet Broker profile that is attached to a Decryption policy rule to pre-10.1 firewalls that have Decryption Broker licenses installed. The Action for the rule (Options tab) must be Decrypt and Forward and you must attach the Packet Broker profile to the rule (Decryption Profile setting on the Options tab). Pre-11.0 firewalls use the Packet Broker profile as the Decryption Forwarding profile for Decryption Broker. The Decryption policy rule determines the traffic to which the firewall applies the profile.
    The traffic that the Decryption policy rule controls must be decrypted SSL traffic (Decryption Broker doesn’t support encrypted SSL traffic or cleartext traffic).
  • When you upgrade from PAN-OS 10.0 to PAN-OS 10.1, only local Decryption policy rules that are used for Decryption Broker are migrated to Network Packet Broker rules. Decryption Broker policy rules that were pushed from Panorama to firewalls are migrated automatically on Panorama but are not migrated automatically on the firewall. Decryption Broker policy rules configured locally on a firewall are migrated to Network Packet Broker rules on that firewall only. For rules configured on Panorama, Panorama must do another commit push to the firewall to synchronize the Decryption Broker rules that were migrated to Network Packet Broker rules on Panorama.
  • When you downgrade from PAN-OS 11.0 to PAN-OS 10.0, Network Packet Broker rules are removed automatically.
Network Packet Broker also has a few usage limitations:
  • If the Network Packet Broker firewall also performs source network address translation (SNAT) and the traffic is cleartext traffic, then the firewall performs NAT on the traffic and forwards the traffic to the security chain. The security chain appliances only see NAT addresses, not the original source addresses:
    1. The firewall performs NAT on the client’s traffic.
    2. The firewall forwards the traffic to the security chain and any routing must be based on the NAT address.
    3. Because the source address in the packet is now the NAT address, the security chain appliances only see the NAT address. They do not see the actual client source address.
    4. When the security chain returns the traffic to the firewall, the result is that the firewall doesn’t know who the user is.
    You can find out who the source user was for a session by checking the Traffic logs for that session and correlating the packet with those logs. Traffic logs include both the original source address, from which you can determine the source user, and the SNAT address.
    You can avoid this scenario by performing NAT on a device other than the firewall.
  • Decrypted SSH, multicast, and broadcast traffic are not supported.
  • Client authentication is not supported for SSL Inbound Inspection when RSA certs are used.
  • In layer 1 Transparent Bridge mode, if a security chain fails, there’s no failover because when you use Transparent Bridge connections, each pair of dedicated Network Packet Broker firewall interfaces connect to one security chain only. (You can’t route traffic on layer 1, you can only forward it to the next connected device.)
  • You can forward IPv6 traffic only in layer 1 Transparent Bridge mode. You cannot forward IPv6 traffic in Routed (layer 3) mode.
  • You cannot use tunnel or loopback interfaces as Network Packet Broker interfaces.
  • Network Packet Broker interfaces cannot use dynamic routing protocols.
  • Both interfaces must be in the same zone.
  • Devices in a security chain cannot modify the source IP address, destination IP address, source port, destination port, or protocol of the original session because the firewall would be unable to match the modified session to the original session and therefore would drop the traffic
  • High Availability for Network Packet Broker is supported only for Active/Passive HA firewall pairs. High Availability for Network Packet Broker is not supported for Active/Active firewall pairs.
  • High Availability is not supported for SSL traffic. SSL Sessions reset on failovers.
  • When you upgrade from PAN-OS 10.0 to PAN-OS 10.1, local Decryption policy rules that are used for Decryption Broker are migrated to Network Packet Broker rules.
  • When you downgrade from PAN-OS 11.0 to PAN-OS 10.0, Network Packet Broker rules are removed automatically.