Networking Features

Networking Features

Table of Contents

Networking Features

What new Networking features are in PAN-OS 11.1?
The following section describes new networking features introduced in PAN-OS 11.1.

Per Policy Persistent DIPP

December 2023
  • Enhancement introduced in PAN-OS 11.1.1.
  • When persistent NAT for DIPP was first introduced in 10.1.6, you configured it for the firewall globally. With the enhanced feature in PAN-OS 11.1.1, you configure persistent DIPP in individual NAT policy rules rather than globally. When you are using NAT or NAT64 for video or voice applications behind the firewall and you need to access STUN, create a NAT rule where the source translation type is Persistent Dynamic IP and Port.
  • Per policy persistent DIPP allows regular (non-persistent) DIPP and persistent DIPP to coexist because persistent DIPP isn't global; the granularity is within a NAT policy rule. When persistent DIPP is configured globally, there are only 64,512 source ports available system-wide, restricting the total number of translations even for regular DIPP traffic. By allowing regular DIPP and persistent DIPP rules to coexist in the system, regular DIPP doesn't have to share ports with persistent DIPP, and can have an oversubscription rate greater than 1, unleashing the total number of regular DIPP translations.
  • Regular DIPP rules and persistent DIPP rules can be translated to the same IP address ranges. For best performance, configure persistent DIPP and regular DIPP to manage separate source port pools because the traffic should go to different destinations.
Some applications, such as VOIP and video, use DIPP source NAT and may require STUN. DIPP NAT uses symmetric NAT, which may have compatibility issues with STUN. To alleviate those issues, persistent NAT for DIPP provides additional support for connectivity with such applications. When you enable persistent NAT for DIPP, the binding of a private source IP address and port to a specific public (translated) source IP address and port persists for subsequent sessions that arrive having that same original source IP address and port.

Software Cut-Through Support for PA-3400 and PA-5400 Series Firewalls

December 2023
  • Introduced in PAN-OS 11.1.1.
The PA-3400 Series and PA-5400 Series (excepting the PA-5450) firewalls have significantly improved latency.

Improved Throughput with Lockless QoS

November 2023
  • Introduced in PAN-OS 11.1.0
The Palo Alto Networks QoS implementation now supports a new QoS mode called lockless QoS for PA-3410, PA-3420, PA-3430, PA-3440, PA-5410, PA-5420, PA-5430, PA-5440, and PA-5445 firewalls. For firewalls with higher bandwidth QoS requirements, the lockless QoS dedicates CPU cores to the QoS function that improves QoS performance, resulting in improved throughput and latency.

Dynamic IPv6 Address Assignment on the Management Interface

November 2023
  • Introduced in PAN-OS 11.1.0
The management (MGT) interface on the NGFW now supports dynamic IPv6 address assignment. Configuring the MGT interface for dynamic IPv6 address assignment (rather than a static address) makes it easier to insert and manage the firewall in an IPv6 network.
When you configure the MGT interface, you'll notice new IPv4 and IPv6 tabs to separate the configurations.
You have two types of addressing to choose from: stateful or stateless. On the network segment, you control the router where you set flags to indicate that the MGT interface will be one of the following:
  • A stateful DHCPv6 client, which receives its IPv6 address with prefix length and other configuration information from a DHCPv6 server.
  • An IPv6 stateless address autoconfiguration (SLAAC) client, which autogenerates its IPv6 address. A stateless IPv6 address avoids a DHCPv6 server having to store dynamic state information about clients; such avoidance is helpful in environments with a large number of endpoints.
The firewall uses Neighbor Discovery Protocol (NDP) to send a Router Solicitation to all routers on the link. The flags in the Router Advertisement (RA) that the sole router (or preferred router) on the link sends to the firewall control whether the firewall will use SLAAC or stateful DHCPv6 to get a dynamic address for the MGT interface.
However, the current situation is that when the Autonomous (A) flag is set in the RA message, the firewall chooses both a DHCPv6 address and a SLAC address. Ideally, the firewall should choose only the SLAAC address and shouldn't send a DHCPv6 Solicit message. As a result of this known issue, if there is a DHCPv6 server on the segment and it can assign an IPv6 address, the firewall prefers DHCPv6 address assignment over SLAAC.
You specify either a static IPv6 default gateway address or request a dynamic IPv6 default gateway address, which the firewall learns from the RA that the router sends. Even if you configure the MGT interface with a static IPv6 address, you now have this same choice for configuring the default gateway.
Therefore, you have four possible options for configuring the MGT interface and its default gateway:
  • Static IPv6 address and static IPv6 default gateway address
  • Static IPv6 address and dynamic IPv6 default gateway address
  • Dynamic IPv6 address and static IPv6 default gateway address
  • Dynamic IPv6 address and dynamic IPv6 default gateway address
Configuring the MGT interface as a DHCPv6 client involves requesting a Non-Temporary or Temporary Address, deciding on the Rapid Commit option, and specifying the DHCPv6 Unique ID type.

PPPoE Client for IPv6

November 2023
  • Introduced in PAN-OS 11.1.0
The firewall supports an Ethernet Layer 3 interface or subinterface acting as a Point-to-Point Protocol over Ethernet (PPPoE) IPv6 client to reach an ISP that provides IPv6 internet services. In PPPoE mode, the interface or subinterface can obtain an IPv6 address dynamically using DHCPv6 either in stateful or stateless mode. In stateful mode, the PPPoE interface acquires all connection parameters dynamically from the DHCPv6 server. In stateless mode, the IPv6 address of the PPPoE interface is obtained using stateless address autoconfiguration (SLAAC), but the other parameters (DNS and prefix delegation) are obtained through DHCPv6. Stateful and stateless DHCPv6 reduce provisioning effort and errors, and simplify address management.
Only Ethernet Layer 3 interfaces and subinterfaces support an IPv6 PPPoE client (tunnel, AE, VLAN, and loopback interfaces don't support an IPv6 PPPoE client). A Layer 3 interface and its subinterface can't act as a PPPoEv6 client at the same time.
A limitation is that the interface configured with PPPoEv6 can't acquire a DNS server address or DNS prefix from Router Advertisement (RA-DNS). You'll have to rely on DHCPv6 to obtain the DNS information or configure those parameters manually.
Once configured for PPPoE, an interface can't be assigned a static IP address.

Post-Quantum IKEv2 VPNs

November 2023
  • Introduced in PAN-OS 11.1.0
Post-quantum VPNs resist attacks based on quantum computing and post-quantum cryptography (PQC). Palo Alto Networks post-quantum VPN support enables you to configure quantum-resistant IKEv2 VPNs and is based on the RFC 8784 standard to maximize interoperability with other vendors' equipment and with future standards. Multiple government agencies around the world, including the NSA and NIAP, recommend implementing RFC 8784 to improve quantum resistance. Implementing RFC 8784 is the simplest way to create quantum-resistant VPNs because you don't need to upgrade crypto elements.
Addressing the quantum threat immediately is critical to defend against Harvest Now, Decrypt Later attacks that target long-lived data because the development of cryptographically relevant quantum computers (CRQCs) will vastly reduce the amount of time required to break classical encryption.
Configuring quantum-resistant VPNs can prevent attackers from recording critical encrypted key material and thus prevent them from decrypting the data even if they steal it. If you have long-lived data, start planning now for the threat posed by quantum computers and quantum cryptography and for your network's transition to a post-quantum world. The first step is to make your VPN connections quantum-resistant.
RFC 8784 provides a transition from today's classical cryptography to PQC. Quantum-resistant VPNs based on RFC 8784 enable using post-quantum pre-shared keys (PPKs) that are not transmitted with the data, so harvesting attacks fail because they don't capture the key material that they need to decrypt the data later. A PPK is a complex, strong hexadecimal string that you statically program into the IKE peers at the ends of the VPN tunnel.
Adding a static PPK that's delivered out-of-band to the classical Diffie-Hellman (DH) key prevents Shor's algorithm from cracking the key because the key is no longer based on prime numbers. RFC 8784 enables using long, strong PPKs that meet the NIST Category 5 security level.
In addition, RFC 8784 provides the backward compatibility to fall back to classical cryptography if a peer can't support FRC 8784, so the implementation doesn't risk refusing legitimate connections. Palo Alto Networks implementation of RFC 8784 provides flexibility and quantum resistance for your IKEv2 VPNs:
  • You can add up to ten post-quantum (PQ) PPKs to each IKEv2 VPN. Each PQ PPK is associated with a PPK KeyID, which uniquely identifies the PPK, so you can configure up to ten PPK + KeyID pairs. You can configure PPKs yourself or use a built-in tool to generate strong PPK strings. Configuring multiple active PPKs enables the firewall that initiates the IKEv2 peering to randomly select one of the active PPKs to use with the peer.
  • You can configure PPK strings from 16-64 bytes (32-128 characters) in length. For best security, use PPK strings that are at least 32 bytes (64 characters) in length.
  • You can set the
    Negotiation Mode
    to control the ciphers used to establish the connection:
    • Mandatory
      —Require that the responding peer use RFC 8784 and abort the connection if it only uses classical cryptography.
    • Preferred
      —Allow the initiating device to fall back to classical cryptography if the peer doesn't support RFC 8784.
  • You can activate and deactivate individual PQ PPKs, so if a PQ PPK is lost or exposed, you can disable it and remove it from the negotiation pool.
In addition to implementing RFC 8784 now:
  • Migrate to tougher cipher suites. Follow RFC 6379 for Suite B Cryptographic Suites for IPsec, upgrade ciphers to Suite-B GCM-256, and avoid using weaker AES-128-bit algorithms.
  • Upgrade to larger hash sizes such as SHA-384 or SHA-512. Don't use MD5 or SHA-1.
  • Upgrade your CA to larger RSA key sizes. Use 4096-bit RSA key sizes and migrate VPN certificate authentication to new certificates.
The following example topology shows three VPN termination sites. Sites A and C support post-quantum VPNs based on RFC 8784. Site B supports only classical VPNs. Site A must be able to communicate with both Site B and Site C.
Site A uses both Mandatory and Preferred negotiation modes. When Site A communicates with Site B, which only supports classical cryptography, Site A falls back to classical negotiation. When Site A communicates with Site C, Site A uses a PQ PPK because Site C supports using PQ PPKs.

New Platform Support for Web Proxy

November 2023
  • Introduced in PAN-OS 11.1.0
The web proxy feature is now supported on the PA-5400 series, which includes the PA-5410, PA-5420, PA-5430 PA-5440 and PA-5445 platforms.

Throughput Enhancements for Web Proxy

November 2023
  • Introduced in PAN-OS 11.1.0
The throughput for both the explicit and transparent components of the web proxy has been significantly improved, resulting in better performance at scale.

Authentication Exemptions for Explicit Proxy

November 2023
  • Introduced in PAN-OS 11.1.0
If you use the explicit proxy configuration for your web proxy, you can now
configure exemptions
for traffic from specific sources, destinations, or both. IoT devices, such as printers, cannot respond to an authentication request from the proxy or support a certificate or PAC file for authentication. You can configure up to three authentication exemptions for devices using the explicit proxy.

Exclude All Explicit Proxy Traffic from Authentication

November 2023
  • Introduced in PAN-OS 11.1.0
If you do not require authentication for your explicit proxy traffic, you can
exclude all explicit proxy traffic
from authentication. If you enable this option, the firewall or Panorama does not authenticate any explicit proxy traffic and does not create any logs for authentication events.

5G Cellular Interface for IPv4

November 2023
  • Introduced in PAN-OS 11.1.0
If you have a PA-415-5G firewall, you can now configure a 5G interface for IPv4 cellular traffic. The PA-415-5G is similar to the PA-415 except that it contains an integrated 5G module to support 4G/5G capability and configuration of an interface for IPv4 cellular traffic.
The 5G cellular interface enables configuration of a primary internet connection as well as configuration of a secondary connection for redundancy in case the primary connection is not available. This type of interface supports data connectivity over the 5G mobile network; if the 5G network is unavailable, the firewall automatically switches to a 4G or 3G network, depending on availability.
To enable the 5G cellular interface, configure an Access Point Name (APN) profile. The APN profile specifies which network or networks the device can access and whether the device receives a dynamic or static IP address.
You can configure a primary and secondary SIM card if it is available. If you have a secondary SIM card, you can configure the firewall to switch from one SIM card to another if one SIM card becomes unavailable. For security, enable a PIN code for the SIM card to prevent misuse. If you cannot remember the PIN code, you must obtain a Personal Unblock Key (PUK) for the SIM card to unlock it for use.
For monitoring purposes, you can enable the Dashboard widgets to view more information about the status of the 5G network.

Recommended For You