Multi-VSYS support for PA-7500 Series firewalls in clustering mode enables you to efficiently use your firewalls with large virtual system capacity. This feature brings parity with standalone systems, allowing you to configure up to 25 virtual systems on your clustered PA-7500 Series firewalls. You can assign virtual systems at the interface level, including support for MC-LAG and Aggregate Ethernet interfaces. This capability is crucial for customers migrating from PA-7050 NGFWs in HA active/passive or active/active configurations to PA-7500 clustering, as it allows you to carry over your existing multi-VSYS configurations.

The feature supports per-VSYS policies, including security rules, NAT rules, and policy-based forwarding. It also enables role-based administration, local user databases, and services such as syslog and SNMP for each virtual system. By implementing multi-VSYS in NGFW clustering mode, you can efficiently separate traffic and management functionality per department. This feature is particularly valuable to large enterprises, service providers, and organizations across various vertical markets that require robust network segmentation and multi-tenancy capabilities in their high-performance firewall deployments.

Internet Service Providers (ISPs) often assign dynamic IPv6 addresses to Next-Generation Firewalls (NGFWs) using DHCPv6, PPPoEv6, or cellular connections. However, some ISPs, especially cellular providers, may not provide a delegated IPv6 prefix that the firewall can use to assign addresses to devices on the local area network (LAN). Additionally, even when a delegated prefix is available, some network administrators may prefer not to use it externally to avoid exposing internal network addressing.

This new capability allows you to use NPTv6 with dynamically assigned IPv6 address prefixes with dynamically assigned IPv6 address prefixes, solving both of these challenges. This enhancement builds upon the existing NPTv6 functionality that previously only supported statically configured IPv6 prefixes.

This feature is for network administrators who need to provide IPv6 connectivity to their LAN hosts when the ISP does not delegate a routable IPv6 prefix or when the organization requires internal address privacy. It is especially useful for deployments in environments that rely on cellular ISPs

The firewall translates the dynamic IPv6 prefix from the ISP into an internal, non-routable prefix for the LAN. This enables seamless IPv6 connectivity for internal hosts while keeping your network's addressing private. The firewall automatically manages the dynamic prefix changes from the ISP, ensuring uninterrupted service without manual intervention.

The key benefits of the feature are that it:

• Ensures LAN Connectivity: Provides IPv6 connectivity to internal hosts even when the ISP does not delegate a prefix.
• Enhances Privacy: Protects your internal network addressing from external exposure.
• Simplifies Management: Automates the translation process for dynamic IPv6 prefixes, reducing the need for manual configuration updates.
• Supports Flexible Deployments: Enables secure and reliable IPv6 connectivity in diverse environments, including those using cellular backhaul.

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

Many organizations face the problem of connecting branch offices or remote sites in locations that don't have access to traditional internet providers. The challenge is even greater when a site's only option is a cellular network that uses only IPv6.

The PA-415-5G firewall addresses this by supporting dynamic IPv6 addressing on it cellular interface. This feature allows the firewall to obtain a dynamic IPv6 prefix from a cellular provider, establishing a direct connection to your corporate network even when the ISP only offers IPv6. The firewall can also be configured with a dual-stack configuration to support both IPv4 and IPv6 traffic over the same cellular interface.

This new capability ensures that remote locations can maintain a secure and reliable connection to the rest of your organization. It expands the options available for connecting your business, enabling you to deploy a firewall in any location with a 5G cellular 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.

To resolve this, PAN-OS now supports proxy IDs in transport mode to enable a seamless connection. You can configure proxy ID in IPSec transport mode only using the CLI command.

Many organizations rely on explicit proxy servers to filter and control outbound internet traffic. Previously, this setup created a security gap: users could not fully enable core components of Palo Alto Networks Advanced cloud service subscriptions—including Advanced WildFire®: Inline Cloud Analysis, Advanced Threat Prevention: Inline Cloud Analysis, Inline Deep Learning Analysis for Advanced URL Filtering, App-ID™ Cloud Engine, and Enterprise DLP—because these features required direct internet connectivity. This limitation meant users with explicit proxy servers were unable to maximize their security posture across their entire environment.Explicit Proxy Support for Advanced Cloud Service Products resolves this challenge. This new feature allows the firewall to successfully establish connectivity to Palo Alto Networks Advanced cloud services through an explicit proxy server. You can now ensure consistent security enforcement and threat analysis across all your web traffic, regardless of how you route outbound connectivity, thereby maintaining full feature functionality and strengthening your overall network security. To enable explicit proxy support for advanced services, refer to the configuration documentation for the specific advanced subscription service.

Managing large, segmented network environments can be difficult when you can't reuse the same IP address across multiple firewall interfaces. Beginning with PAN-OS^® release 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 the same zone on different virtual systems, or 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 require extremely high levels of network bandwidth and reliability. A single point of failure can disrupt network connectivity and compromise security. Next-Generation Firewall (NGFW) clustering solves this problem by providing a single, unified high availability solution for two PA-7500 Series firewalls. This solution offers redundancy and increased resilience against link, card, or chassis failures, ensuring business continuity.

The NGFW cluster solution blends legacy active/active and active/passive solutions into a single architecture, significantly simplifying deployment and reducing failover time. 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 supports a multichassis link aggregation group (MC-LAG). The firewalls in the cluster increase port availability and require fewer IP addresses, providing a more efficient and resilient network.

In prior releases, customers with PA-5420 firewalls faced a limitation when configuring a large number of virtual systems. The previous limit of 50 virtual routers made it challenging to deploy a dedicated virtual router for each virtual system, which is a common practice for maintaining network segmentation and administrative simplicity. This limitation often required administrators to merge virtual systems or implement more complex, less scalable routing configurations.

To solve this challenge, PAN-OS® increases the number of supported virtual routers on a PA-5420 firewall from 50 to 65. This enhancement allows you to assign a unique virtual router to each virtual system, providing greater administrative flexibility and simplifying network design. You can now support up to 65 virtual systems, each with its own virtual router, to maintain clear separation and streamline routing management across your network. This increase is particularly valuable for service providers and large enterprises that manage many tenants or independent network segments on a single firewall.

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.

Many real-time communication applications, like VoIP and video conferencing, rely on Session Traversal Utilities for NAT (STUN) to establish and maintain stable connections. However, when these applications are deployed with Dynamic IP and Port (DIPP) source NAT, they can experience connectivity issues. This happens because DIPP uses a symmetric NAT approach, which can change the translated IP address and port for each new session. This frequent change can cause compatibility problems with STUN, often resulting in dropped calls or one-way audio for users.

Persistent NAT for DIPP solves this problem by ensuring a consistent and predictable translation for a given internal source IP and port. When you enable this feature, the mapping between a private source IP address and port and its public translated address and port persists for subsequent sessions. This stable binding is crucial for maintaining seamless, uninterrupted communication, providing the reliable connectivity that real-time applications demand.

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.

Manually configuring static IPv6 addresses on a firewall's management (MGT) interface can be time-consuming and complex, especially in large, dynamic network environments. To solve this, your Next-Generation Firewall (NGFW) now supports dynamic IPv6 address assignment on its management (MGT) interface. This makes it easier to insert and manage the firewall in an IPv6 network.

The firewall's MGT interface can dynamically receive its IPv6 address from a stateful DHCPv6 client or an IPv6 stateless address autoconfiguration (SLAAC) client. A stateful client receives its address and configuration information from a DHCPv6 server. A stateless client, on the other hand, automatically generates its own address. This is especially helpful in environments with a large number of endpoints because it avoids the need for a DHCPv6 server to store dynamic state information about each client.

The firewall can also dynamically learn its default gateway from the router’s Router Advertisement (RA) message. This option is available even when you configure a static IPv6 address on the MGT interface. This new flexibility allows you to choose from various combinations for the MGT interface and its default gateway, including both static and dynamic address assignments.

The PAN-OS® 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.

Cryptographically relevant quantum computers (CRQCs) threaten traditional cryptographic systems by dramatically reducing the time needed to break encryption algorithms. VPN communications secured by IKEv2 are vulnerable to the threats posed by CRQCs because IKEv2 uses Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) for key exchange. Delays in implementing post-quantum cryptography (PQC) increase the risk of Harvest Now, Decrypt Later attacks. In these attacks, adversaries capture and store encrypted data today for future decryption when CRQCs become available. If you handle sensitive data requiring long-term storage, you are especially susceptible.

To future-proof VPN communications against this emerging threat, PAN-OS® 11.1 implements quantum-resistant IKEv2 VPNs based on RFC 8784. RFC 8784 specifies the mixing of post-quantum pre-shared keys (PQ PPKs) with DH keys to create quantum-resistant connections. The implementation involves a PQ PPK and a public key ID associated with the secret. You must share the secret with both VPN peers out-of-band. After the peers perform a standard DH key exchange, one peer sends the key ID to the other in-band. Both peers use that key ID to identify the PQ PPK to mix with the DH key material. This method creates a new, quantum-resistant key that provides multiple layers of protection. CRQCs can't compromise the resulting key because it isn't based on prime number factorization that Shor's algorithm exploits. Harvesting attacks fail because the PPK itself never leaves your IKEv2 peers; adversaries can't capture the key material required for future decryption, even if they compromise the DH key.

Palo Alto Networks implementation of RFC 8784 ensures a seamless transition to PQC. The standard doesn't require cryptography upgrades, so you can introduce PPKs into existing IPsec VPN deployments without network disruption. It also supports falling back to classical cryptography if a peer doesn't support RFC 8784. Further, the standard is interoperable with multiple vendors and works with other standards such as RFC 9370.

The following example topology shows three VPN termination sites. Sites A and C support post-quantum VPNs based on RFC 8784, while Site B supports classical VPNs only. Site A must be able to communicate with both Site B and Site C. When communicating with Site B, Site A can either fall back to classical negotiation or abort the connection, depending on your configured preference. When communicating with Site C, Site A uses a PQ PPK because Site C supports this.

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.