Beginning with PAN-OS 11.1.5, you can set up an IKE gateway on an interface that has a dynamically assigned IPv6 address configured by DHCPv6, PPPoEv6, or a 5G modem. (Setting up an IKE gateway on an interface with a static IPv6 address was already possible.)

The PA-415-5G firewall supports dynamic IPv6 addressing and dual-stack networking on a cellular interface. This is especially helpful when your cellular operator provides only IPv6 services or your location requires IPv6 connectivity. The cellular interface supports dynamically obtaining an IPv6 prefix from the 5G provider network.

In the earlier PAN-OS versions, the IPSec transport mode did not support proxy ID settings for IPSec negotiation. Hence, you could not configure a proxy ID in transport mode when using the web interface. If you try to configure a proxy ID through the CLI, it will be replaced with 0.0.0.0/0 automatically during the configuration commit. With the lack of proxy ID support, connecting to other vendor’s devices through policy-based IPSec transport mode was leading to communication failure.

We’ve now introduced support for proxy ID in transport mode that enables you to have a seamless connection. You can configure proxy ID in IPSec transport mode only using the CLI command.

Palo Alto Networks now provides support for Advanced cloud-based features (including, but not limited to Precision AI™ optimized features such as Advanced WildFire: Inline Cloud Analysis, Advanced Threat Prevention: Inline Cloud Analysis, Inline Deep Learning Analysis for Advanced URL Filtering; as well as App-ID Cloud Engine, and Enterprise DLP) when using an explicit proxy as part of a customer's network security infrastructure. Previously, access to various components of advanced security subscriptions required direct internet connectivity, preventing users from maximizing the feature set of their advanced cloud services when internet traffic is handled by an explicit proxy server, which could leave them vulnerable to certain security threats. When Explicit Proxy Support for Advanced Services is enabled, the firewall initiates and completes a proxy handshake and authentication procedures to establish connection to the specified proxy server, which subsequently forwards traffic to the Palo Alto Networks Advanced cloud service servers via the proxy.

For more information about enabling explicit proxy support for advanced services, refer to the configuration documentation for enabling the specific advanced subscription service.

Without the ability to reuse the same IP address across multiple interfaces, it can be difficult to manage large environments where the firewall resources are shared or segmented. Beginning with PAN-OS 11.1.4, duplicate (overlapping) IP address support allows you to use the same IPv4 or IPv6 address on multiple firewall interfaces when the interfaces belong to different logical routers. The interfaces can belong to different security zones on a single virtual system, or belong to the same zone on different virtual systems, or belong to different zones and different virtual systems.

PA-1400 Series firewalls, VM-Series firewalls, and Panorama template stacks support overlapping addresses.

Overlapping IP address support requires the Advanced Routing Engine. When you enable Advanced Routing, the option to enable Duplicate IP Address Support becomes available for you to select. The overlapping addresses can be statically configured or dynamically assigned to interfaces. All Layer 3 interfaces types (Ethernet, VLAN, tunnel, loopback, Aggregate Ethernet [AE], and AE subinterfaces) support overlapping IP addresses.

Data centers need very high levels of network bandwidth and reliability. NGFW clustering is a way to provide redundancy to two PA-7500 Series firewalls in an NGFW cluster in the event of a link failure, card failure, or chassis failure. NGFW clustering blends the legacy HA active/active and active/passive solutions into a single high availability solution. The two cluster nodes connect over a single HSCI connection. The firewalls maintain a dual active data plane with a single active control plane. Neighboring devices see the NGFW cluster as a single Layer 2 (virtual wire) or Layer 3 device.

The NGFW cluster solution reduces failover time, increases resiliency, and supports a multichassis link aggregation group (MC-LAG). The firewalls in the NGFW cluster increase port availability, require fewer IP addresses, and rely on open standards.

The number of virtual routers supported on a PA-5420 firewall increased from 50 to 65. This increase allows you to have a virtual router for each virtual system on the firewall in the event that you configure more than 50 virtual systems.

Beginning with PAN-OS 10.1 and later releases, we support Username/password and Satellite Cookie Authentication method for a satellite to authenticate to the portal. This method requires user intervention to get satellites authenticated by a portal that prevents automating the deployment of remote satellites and adds difficulty and complexity for the administrators to perform software upgrade and deploy new firewalls.

To remove the user intervention while onboarding a remote satellite and to enable automating the deployment of remote satellites, we introduce a new authentication method called Serial number and IP address Authentication. You can now onboard a remote satellite using the combination of serial number and IP address in addition to the username/password and satellite cookie authentication method. This authentication method reduces the complexity by enabling you to deploy new firewalls without manual intervention.

However, Username/password and Satellite Cookie Authentication remains as a default authentication method.

Before enabling the Serial number and IP address Authentication method, configure the satellite serial number at the portal as one of the authentication verification conditions.

Upon successfully configuring a satellite device allowed IP address list per portal, and configuring the satellite serial number on the GlobalProtect portal, the satellite can initiate the connection to the portal.

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.

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.

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:

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.

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.

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:

In addition to implementing RFC 8784 now:

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.

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.

The throughput for both the explicit and transparent components of the web proxy has been significantly improved, resulting in better performance at scale.

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.

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.

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.

As multiple cellular carriers release new firmware updates to address issues and add new capabilities, managing these firmware updates and ensuring users receive them in a timely manner quickly becomes a complex but critical task. Depending on what type of deployment you have, there could be multiple carriers and versions to manage, which significantly adds to the scale and time commitment necessary for this task.

To simplify the process of updating the firmware for your 5G interface, you can now use a device web interface to review, manage, and install the latest firmware updates available from supported carriers. All you need to do is select the firewall model and the carrier type, then download the firmware updates from the Customer Support Portal. Once this is complete, you can then install the updates on the firewall as the latest firmware version. After you confirm the installation, this allows the firewall to push the updated firmware to the appropriate users on your network. You can also optionally use the Customer Support Portal to view checksum information and read the release notes for the available firmware updates to find out more about the changes in this update.

Updating firmware is a key step in ensuring that your users get the latest features and support and to protect your network and users from malicious activity. By providing a simplified management tool for quick deployment of firmware updates, Palo Alto Networks can help ensure protection against the latest threats and vulnerabilities for the users on your network.