Network Security
Policy-Based Forwarding
Table of Contents
Expand All
|
Collapse All
Network Security Docs
Policy-Based Forwarding
Learn how policy-based forwarding allows override the routing table and
send packets through a specified egress port.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
|
Normally, the firewall uses the destination IP address
in a packet to determine the outgoing interface. The firewall uses
the routing table associated with the virtual router to which the
interface is connected to perform the route lookup. Policy-Based Forwarding
(PBF) allows you to override the routing table, and specify the
outgoing or egress interface based on specific parameters
such as source or destination IP address, or type of traffic.
PBF rules allow traffic to take an alternative path from the next
hop specified in the route table, and are typically
used to specify an egress interface for security or
performance reasons. Let's say your company has two
links between the corporate office and the branch
office: a cheaper internet link and a more expensive
leased line. The leased line is a high-bandwidth,
low-latency link. For enhanced security, you can use
PBF to send applications that aren’t encrypted
traffic, such as FTP traffic, over the private
leased line and all other traffic over the internet
link. Or, for performance, you can choose to route
business-critical applications over the leased line
while sending all other traffic, such as web
browsing, over the cheaper link.
Egress Path and Symmetric Return
Using PBF, you can direct traffic to a specific
interface on the firewall, drop the traffic, or
direct traffic to another virtual system (on
systems enabled for multiple virtual systems).
In networks with asymmetric routes, such as in a
dual ISP environment, connectivity issues occur
when traffic arrives at one interface on the
firewall and leaves from another interface. If the
route is asymmetrical, where the forward (SYN
packet) and return (SYN/ACK) paths are different,
the firewall is unable to track the state of the
entire session and this causes a connection
failure. To ensure that the traffic uses a
symmetrical path, which means that the traffic
arrives at and leaves from the same interface on
which the session was created, you can enable the
Symmetric Return option.
With symmetric return, the virtual router
overrides a routing lookup for return traffic and
instead directs the flow back to the MAC address
from which it received the SYN packet (or first
packet). However, if the destination IP address is
on the same subnet as the ingress/egress
interface’s IP address, a route lookup is
performed and symmetric return is not enforced.
This behavior prevents traffic from being silently
discarded.
To determine the next hop for symmetric
returns, the firewall uses an Address Resolution
Protocol (ARP) table. The maximum number of
entries that this ARP table supports is limited by
the firewall model and the value is not user
configurable. To determine the limit for your
model, use the CLI command: show pbf
return-mac all.
Path Monitoring for PBF
Path monitoring allows you to verify connectivity
to an IP address so that the firewall can direct
traffic through an alternate route, when needed.
The firewall uses ICMP pings as
heartbeats to verify that the
specified IP address is reachable.
A monitoring profile allows you to specify the
threshold number of heartbeats to determine
whether the IP address is reachable. When the
monitored IP address is unreachable, you can
either disable the PBF rule or specify a
fail-over or
wait-recover action. Disabling the
PBF rule allows the virtual router to take over
the routing decisions. When the fail-over or
wait-recover action is taken, the monitoring
profile continues to monitor whether the target IP
address is reachable, and when it comes back up,
the firewall reverts back to using the original
route.
The following table lists the difference in
behavior for a path monitoring failure on a new
session versus an established session.
|
Behavior of a session on a
monitoring failure
|
If the rule stays enabled
when the monitored IP address is unreachable
|
If rule is disabled when
the monitored IP address is unreachable
|
|---|---|---|
|
For an established session
|
wait-recover—Continue to
use egress interface specified in the PBF rule
|
wait-recover—Continue to
use egress interface specified in the PBF rule
|
|
fail-over—Use path
determined by routing table (no PBF)
|
fail-over—Use path
determined by routing table (no PBF)
| |
|
For a new session
|
wait-recover—Use path
determined by routing table (no PBF)
|
wait-recover—Check the
remaining PBF rules. If no match, use the routing
table
|
|
fail-over—Use path
determined by routing table (no PBF)
|
fail-over—Check the
remaining PBF rules. If no match, use the routing
table
|
Service Versus Applications in PBF
PBF rules are applied either on the first packet
(SYN) or the first response to the first packet
(SYN/ACK). This means that a PBF rule may be
applied before the firewall has enough information
to determine the application. Therefore,
application-specific rules are not recommended for
use with PBF. Whenever possible, use a service
object, which is the Layer 4 port (TCP or UDP)
used by the protocol or application.
However, if you specify an application in a PBF
rule, the firewall performs App-ID
caching. When an application passes through
the firewall for the first time, the firewall does
not have enough information to identify the
application and therefore cannot enforce the PBF
rule. As more packets arrive, the firewall
determines the application and creates an entry in
the App-ID cache and retains this App-ID for the
session.When a new session is created with the
same destination IP address, destination port, and
protocol ID, the firewall could identify the
application as the same from the initial session
(based on the App-ID cache) and apply the PBF
rule. Therefore, a session that is not an exact
match and is not the same application, can be
forwarded based on the PBF rule.
Further, applications have dependencies and the
identity of the application can change as the
firewall receives more packets. Because PBF makes
a routing decision at the start of a session, the
firewall cannot enforce a change in application
identity. YouTube, for example, starts as
web-browsing but changes to Flash, RTSP, or
YouTube based on the different links and videos
included on the page. However with PBF, because
the firewall identifies the application as
web-browsing at the start of the session, the
change in application is not recognized
thereafter.
You cannot use custom applications, application
filters, or application groups in PBF rules.