Networking Features
Focus
Focus

Networking Features

Table of Contents
End-of-Life (EoL)

Networking Features

PAN-OS 9.0 supports new networking features.
New Networking Feature
Description
Security Group Tag (SGT) EtherType Support
If you're using Security Group Tags (SGTs) in a Cisco TrustSec network, inline firewalls in Layer 2 or Virtual Wire mode can now inspect and enforce the tagged traffic. Layer 3 firewalls in a Cisco TrustSec network can also inspect and enforce SGT traffic when deployed between two SGT exchange protocol (SXP) peers.
Processing of SGT traffic works by default and without any configuration changes. Because the firewall does not use SGTs as match criteria for security policy enforcement, you should continue to define SGT-based policy in the same way you do today.
FQDN Refresh Enhancement
With cloud applications requiring frequent FQDN refresh rates to ensure nonstop services, the FQDN refresh feature now supports the ability to refresh cached entries based on the DNS TTL value. You can set a minimum FQDN refresh time to limit how frequently the firewall will refresh the FQDN cache entries to avoid refreshing too frequently, and state how long the firewall continues to use FQDN cached entries in the event of a network failure where the DNS server is unreachable.
GRE Tunneling Support
The firewall can now be a GRE tunnel endpoint, so you can send traffic through a GRE tunnel to a point-to-point tunneling peer, and the firewall will inspect and enforce policies as it does for non-tunneling traffic. Cloud services and partner networks often use GRE tunnels for point-to-point connectivity to customer networks. The firewall also supports GRE over IPSec to interoperate with other vendors’ implementations in deployments that encrypt GRE within IPSec.
Wildcard Address Support in Security Policy Rules
When you define private IPv4 addresses to internal devices, you can use an IP addressing pattern that assigns special meaning to certain bits in the IP address. For example, the first three bits in the third octet of an IP address might signify the device type. This structure helps you easily identify device type, location, and other information, based on the IP address of the device. You can also use your same address structure in Security policy rules on the firewall for easier deployment. Additionally, you can now build Security policy rules based on sources and destinations that use a wildcard address and use only specific bits in an IP address as a match. This means you don’t need to manage an unnecessarily large number of address objects to cover all the matching IP addressees or use less restrictive Security policy rules than needed due to IP address capacity constraints. For example, a rule using a single wildcard address can allow all cash registers in the northeastern region of the U.S. to access a specific application. This helps make your Security deployment easier in an environment that uses a discontiguous addressing scheme.
Hostname Option Support for DHCP Clients
When your firewall interface is a DHCP client (a DHCP server assigns a dynamic IPv4 address to the interface), you can now assign a hostname to the interface and send the hostname (Option 12) to the DHCP server. The DHCP server can register the hostname with the DNS server, which can automatically manage hostname-to-dynamic IP address resolutions.
FQDN Support for Static Route Next Hop, PBF Next Hop, and BGP Peer
You can now use an FQDN or FQDN address object in a static route next hop, a PBF next hop, and a BGP peer address. Use of FQDNs reduces configuration and management overhead. Also, in order to simplify provisioning, you can use an FQDN (instead of statically assigning IP addresses to these functions) and the FQDN resolution can change from location to location. You can map the FQDN to the IP address based on the location and deployment requirements. For example, if you are a service provider, you can provide FQDNs for accessing the services and resolve these to the IP address of the closest server for the client (based on the client’s geo-location), so that the same FQDN can be used globally for the service connection.
Dynamic DNS Support for Firewall Interfaces
When you have services hosted behind the firewall or you need to provide remote access to the firewall, you can now automatically register IPv4 and IPv6 address changes to a Dynamic DNS (DDNS) provider whenever the IP address on the firewall interface changes (for example, if the interface is a DHCP client). The firewall registers the change with the DDNS service, which automatically updates the DNS record (IP address-to-hostname mappings). DDNS support helps avoid using external mechanisms to keep the DNS records up to date. The firewall currently supports five DDNS providers: DuckDNS, DynDNS, FreeDNS Afraid.org, FreeDNS Afraid.org Dynamic API, and No-IP.
HA1 SSH Key Refresh
When you need to change your SSH key pairs to secure HA1 communications, you can now refresh the keys without needing to restart the firewalls.
Advanced Session Distribution Algorithms for Destination NAT
In destination NAT, translation to a pool of IP addresses or an FQDN that resolves to multiple IP addresses can be distributed among the addresses based on one of four additional session distribution methods (or the existing round-robin method). The additional distribution methods are source IP hash, IP modulo, IP hash, and least sessions. You can use the distribution method that best suits your destination NAT use case.
VXLAN Tunnel Content Inspection
If you use VXLAN as a transport overlay you can use Tunnel Content Inspection Policy to natively scan traffic within the VXLAN tunnel. For example, if you use VXLAN as a transport overlay to connect your geographically dispersed data centers you can scan and control the individual flows within the tunnel.
With support for the VXLAN protocol in Tunnel Content Inspection Policy, you have visibility into VXLAN traffic and can enforce Security Policy rules to this traffic without terminating the tunnel or implementing network changes.
LACP and LLDP Pre-Negotiation on an HA Passive Firewall
An HA passive firewall can negotiate LACP and LLDP before it becomes active. This pre-negotiation reduces failover times by eliminating the delays incurred by LACP or LLDP negotiations. This functionality, previously supported on several firewall models, extends to PA-220, PA-220R, PA-820, PA-850, PA-3200 Series, and PA-5280 firewalls.
DNS Rewrite for Destination NAT
(
Available with PAN-OS
®
9.0.2 and later 9.0 releases
)
(
Requires Applications and Threats content release version 8147 or a later version
) You can configure a destination NAT policy rule for a static translation of an IPv4 address to also translate the IPv4 address in a DNS response that matches the rule. This DNS rewrite (translation) prevents the DNS server on one side of the firewall from providing an internal IP address to its client on the external side of the firewall or vice versa. Thus, the IPv4 address in the DNS response undergoes NAT and the firewall forwards the appropriate IPv4 address to the client to reach the destination service.
Ignore DF (don’t fragment) Bit
(
Available with PAN-OS 9.0.9 and later 9.0 releases
)
You can configure the firewall globally to fragment IPv4 packets when the DF (don't fragment) bit is set for packets that exceed the egress interface maximum transmission unit (MTU). This feature is applied to Layer 3 and tunnel interfaces when enabled through the CLI.

Recommended For You