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
|
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
|
The PA-3400 Series and PA-5400 Series (excepting the PA-5450)
firewalls have significantly improved latency.
Improved Throughput with Lockless QoS
November 2023
|
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
|
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
|
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
|
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 theNegotiation Modeto 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
|
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
|
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
|
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
|
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
|
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.