Networking Features

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

(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.