Guidelines for policy based routing

Device Guidelines

  • PBR through Firewall Management Center's Policy Based Routing page is supported only from version 7.1 or later on both the Firewall Management Center and the Firewall Threat Defense device.

  • When you upgrade Firewall Management Center or Firewall Threat Defense to version 7.1 or later, the PBR configuration in the device is removed. You must configure PBR again using the Policy Based Routing page. If the managed device is earlier than version 7.1, you must configure PBR again using FlexConfig with deploy option set to "every time."

  • On cluster devices and Secure Firewall 200, you cannot configure application, user identity, and Security Group Tag (SGT) based PBR policy.

Interface guidelines

  • Configure only routed-mode interfaces and non management-only interfaces in the Global virtual router as ingress or egress interfaces for the PBR policy. You cannot configure user-defined virtual router interfaces for the policy.

  • The interfaces that you want to define in the policy must have a logical name.

  • Configure Static VTIs only as egress interfaces.

  • Do not choose Dynamic VTIs for configuring the PBR egress interfaces.

IP address

You can apply PBR for managing both IPv4 and IPv6 traffic.

Application-based PBR and DNS configuration

  • Application-based PBR uses DNS snooping for application detection. Application detection succeeds only if the DNS requests pass through Firewall Threat Defense in a clear-text format; the DNS traffic is not encrypted.

  • You must configure trusted DNS servers for the application detection to succeed.

For more information on configuring DNS servers, refer to DNS.

PBR policies not applied for output route look-up

Policy Based Routing is an ingress-only feature; The system applies PBR only to the first packet of a new incoming connection, at which time the egress interface for the forward leg of the connection is selected. Note that PBR will not be triggered if the incoming packet belongs to an existing connection, or if NAT is applied and NAT chooses the egress interface.

PBR policies not applied for embryonic traffic

An embryonic connection is where the necessary handshake between source and destination has not been made. When a new internal interface is added and a new VPN policy is created using a unique address pool, PBR is applied to the outside interface matches the source of the new client pool. Thus, PBR sends traffic from the client to the next hop on the new interface. However, PBR does not process return traffic from a host until the new internal interface establishes a connection with the client. Thus, the return traffic from the host to the VPN client, specifically, the VPN client response is dropped as there is no valid route. To prevent the response from being dropped, configure a weighted static route with a higher metric on the internal interface.

HTTP-based path monitoring guidelines

  • Configure HTTP-based path monitoring only on physical, port-channel, subinterfaces, and static tunnel interfaces. Do not configure it on cluster devices.

  • HTTP uses only IPv4 to ping applications. IPv4 metrics are applied for routing and forwarding both IPv4 and IPv6 traffic.

  • HTTP-based application monitoring is enabled by default in Secure Firewall Management Center version 7.4 and higher. However, when you upgrade from previous versions, this option is not enabled by default. You must manually enable it.

Additional guidelines

  • All existing configuration restrictions and route map limitations remain in effect.

  • When you define the ACL for the policy match criteria, you can select multiple predefined applications from a list to form an Access Control Entry (ACE). In Firewall Threat Defense, the predefined applications are stored as Network Service objects and the group of applications as Network Service Groups (NSG). You can create a maximum of 1024 such NSGs. The application or network service group is detected through first-packet classification. Currently, you cannot add to or modify the predefined applications list.

  • Unicast Reverse Path Forwarding (uRPF) validates the source IP address of packets received on an interface against the routing table and not against the PBR route map. When uRPF is enabled, packets received on an interface through PBR are dropped as they are without the specific route entry. Therefore, when using PBR, ensure you disable uRPF.