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 may 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 signify the device type. This structure helps you easily identify device type, location, and so on, based on the device’s IP address. You may also want to use your same address structure in Security policy rules on the firewall for easier deployment. 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. Thus, you won’t have to manage an unnecessarily large number of address objects to cover all the matching IP addressees or use less restrictive Security policy rules than you need 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|
(Requires Applications and Threats content update 8147 or a later version) Beginning with PAN-OS 9.0.2 and later 9.0 releases, 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.
Dynamic DNS Support for Firewall Interfaces
Configure the firewall to use a Dynamic DNS (DDNS) service to update your domain name-to-IP address mappings so DDNS provides accurate IP addresses to DNS ...
Describes all the exciting new capabilities in PAN-OS® 9.0 for the VM-Series firewall. ...
VXLAN Tunnel Content Inspection
Configure tunnel content inspection to scan traffic within a VXLAN tunnel. ...
Building Blocks in a Tunnel Inspection Policy
Building Blocks in a Tunnel Inspection Policy Select Policies Tunnel Inspection to add a Tunnel Inspection policy rule. You can use the firewall to inspect ...
Configure Tunnel Content Inspection
Configure Tunnel Content Inspection Perform this task to configure tunnel content inspection for a tunnel protocol that you allow through a tunnel. Create a Security ...
Configure Dynamic DNS for Firewall Interfaces
Configure the firewall to use a DDNS service to update your changing domain name-to-IP address mappings so it provides accurate IP address resolutions to its ...