Policy Based Forwarding

Policy Based Forwarding Tech Note PAN-OS 4.1 Revision A 2012, Palo Alto Networks, Inc. www.paloaltonetworks.com

Contents Overview... 3 Security... 3 Performance... 3 Symmetric Routing... 3 Service Versus Application... 4 PBF and the Monitor Function... 5 Example Setup... 5 Topology... 5 Routing Configuration... 6 Policy Based Forwarding Configuration... 6 Verification... 6 Conclusion... 8 2012, Palo Alto Networks, Inc. [2]

Overview Policy Based Forwarding or PBF can be used to override the routing table. In some cases, it is desirable to send certain traffic out a link other than what the routing protocol or static route entries dictate. There are many use cases where PBF is applicable. Security In one use case the public Internet is used for most traffic going to and from a branch office. But some applications that aren t encrypted like FTP may carry sensitive information. In this case, you might install a private leased line between the branch office and headquarters. But rather than put all traffic on the more expensive leased line, you can purchase a lower throughput leased line and only use it for certain applications like FTP. Performance Another use case is similar to the security use case where you have two connections to a branch office: a cheaper Internet connection and a more expensive leased line. The leased line has better availability and predictable latency. So in this case, you might want critical business applications (for example traffic going to financial application servers) to use the leased line and less critical applications (like web browsing) to use the Internet connection. Symmetric Routing It is important that a PBF strategy ensures both the originating and the returning traffic use the same path. If the paths are different, then any firewall in the path that sees only traffic from one direction won t be able to track the state of the entire session and the traffic will fail. In the example below, the initial SYN for a new session arrived on ISP-A but because the PBF policy for the firewall didn t align with the interface the traffic arrived on, the corresponding SYN/ACK was routed towards ISP-B. But the firewall tracks state based on zone pairs. The SYN is associated with the Trust-Untrust-A zone pair but the SYN/ACK is associated with the Trust-Untrust-B pair. Because there is no initial SYN for the session associated with the Trust-Untrust-B, the SYN/ACK fails and the session cannot initiate. SYN / ACK SYN Ethernet 1/1: Trust Firewall Ethernet 1/2: Untrust-A Ethernet 1/3: Untrust-B ISP A ISP B 2012, Palo Alto Networks, Inc. [3]

Service Versus Application A Service object in PAN-OS relies only on TCP or UDP ports. For this reason, a PBF policy that uses a service for routing decisions can be applied to all sessions, including the very first one of a given source/destination pair as seen by the firewall. The downside to this technique is an application using a non-standard port might be incorrectly routed. For example, a PBF rule that specifies service-http will apply to SSH traffic if SSH was reconfigured to use TCP 80 instead of TCP 22. In order for PAN-OS to identify an Application, it can take many packets. For example, all HTTP sessions look the same initially. It isn t until PAN-OS sees more packets in the session that it can determine for example that the traffic is YouTube versus Facebook. But as in the diagram above, PBF is applied on the first packet or the first response to the first packet. This means, a PBF rule must be applied before PAN-OS has enough information to determine the application. There is an option to configure PBF rules based in part on the application as shown: The way PAN-OS adds application selection to PBF is to perform app ID caching. With app ID caching, a PBF rule can reference an application. The first time that application passes through the firewall, the firewall is not aware of what the application is initially and the PBF rule is not applied. However, as more packets arrive, PAN-OS is able to determine the application and it creates an entry in the app ID cache. The next time a new session is created with the same IP source and destination and destination port, PAN-OS assumes it is the same application as the initial session (based on the app ID cache) and will then apply the PBF rule. It is important to note several caveats for this technique: The initial session will not use the PBF rule during that session even after PAN-OS is able to determine the app ID o All packets of a session must follow the same path to ensure session state is tracked. The criteria for matching an entry in the app ID cache are only: o Destination IP o IP protocol o Destination port This means all sessions that match these three criteria will have the PBF rule applied even if they are not truly the same application. The list of available applications is shorter than the choices available for a security policy o For example web-browsing is available but YouTube is not 2012, Palo Alto Networks, Inc. [4]

For these reasons, you should use caution before configuring PBF with applications. We recommend using Service wherever possible for the most predictable results. PBF and the Monitor Function One option for PBF is the monitor function. This adds the ability to monitor an IP address and change the PBF behavior if the IP address becomes unreachable. There are two actions in the Monitor Profile to configure the behavior in the event of a monitor IP failure. The two actions are wait-recover and fail-over. The actions have different meanings for established versus new sessions. There is also a Monitor option to disable the rule if the monitor IP is unreachable. The following table documents each scenario: Rule Stays Enabled When Monitor Fails: Rule Disabled When Monitor Fails: wait-recover fail-over wait-recover fail-over Behavior for established sessions during monitor failure Continue to use egress interface specified in PBF rule Use path determined by routing table (no PBF) Continue to use egress interface specified in PBF rule Use path determined by routing table (no PBF) Behavior for new sessions during monitor failure Use path determined by routing table (no PBF) Use path determined by routing table (no PBF) Check the remaining PBF rules. If none match, use the routing table. Check the remaining PBF rules. If none match, use the routing table. Example Setup Topology For this Tech Note the following example topology was setup: Server Firewall WWW ISP-A ISP-B Client Firewall Client 2012, Palo Alto Networks, Inc. [5]

ISP-A is the default route for traffic from the web client Client to access the web server WWW. ISP-B will be used for only TCP 80/8080 traffic between Client and WWW. This will be accomplished using PBF. Routing Configuration The following static routes were added to allow reachability between the WWW server and the Client: Firewall Remote Network Next Hop Metric Server Firewall Client Subnet ISP-A 10 Server Firewall Client Subnet ISP-B 1000 Client Firewall Server Subnet ISP-A 10 Client Firewall Server Subnet ISP-B 1000 This causes ISP-A to be the preferred route between the client and server. Policy Based Forwarding Configuration PBF was configured on the Client Firewall directing all TCP 80/8080 (HTTP service) to ISP-B: In order to ensure all traffic returns on the same path, a complimentary PBF configuration is required on the Server Firewall. Note the service-http selection needs to still be in the Destination column: Verification To verify the configure PBF rules and the monitor state (if applicable) use the following command: warby@pa-4050> show pbf rule all Rule ID Rule State Action Egress IF/VSYS NextHop NextHop Status ========== ===== ========== ======== =============== ======================================= ============== HTTP Retur 1 Active Forward ethernet1/2.102 15.0.2.1 UP SSH with m 2 Active Forward ethernet1/2.102 15.0.2.1 DOWN 2012, Palo Alto Networks, Inc. [6]

For troubleshooting, it is useful to view session details and note the applied PBF rule: warby@pa-5060-1> show session id 2359297 Session 2359297 c2s flow: source: 15.0.6.101 [trust] dst: 15.0.3.101 proto: 6 sport: 37264 dport: 22 state: ACTIVE type: FLOW src user: unknown dst user: unknown pbf rule: SSH with Monitor 4 offload: Yes s2c flow: source: 15.0.3.101 [untrust] dst: 15.0.6.101 proto: 6 sport: 22 dport: 37264 state: ACTIVE type: FLOW src user: unknown dst user: unknown offload: Yes... start time : Thu Jul 5 16:23:55 2012 To verify that HTTP traffic traversed ISP-B and all other traffic traversed ISP-A, ICMP, SSH and HTTP traffic was sent form Client to WWW (15.0.3.101): warby@client:~$ ping -c 3 15.0.3.101 PING 15.0.3.101 (15.0.3.101) 56(84) bytes of data. 64 bytes from 15.0.3.101: icmp_req=1 ttl=61 time=1.70 ms 64 bytes from 15.0.3.101: icmp_req=2 ttl=61 time=1.46 ms 64 bytes from 15.0.3.101: icmp_req=3 ttl=61 time=1.54 ms --- 15.0.3.101 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 1.465/1.571/1.708/0.101 ms warby@client:~$ ssh 15.0.3.101 warby@15.0.3.101's password: warby@client:~$ wget 15.0.3.101 --2012-06-23 07:30:45-- http://15.0.3.101/ Connecting to 15.0.3.101:80... connected. HTTP request sent, awaiting response... 200 OK Length: 177 [text/html] Saving to: `index.html.2' 100%[==============================================================================>] 177 --.- K/s in 0s 2012-06-23 07:30:45 (34.6 MB/s) - `index.html.2' saved [177/177] warby@client:~$ On ISP-A, we see the SSH and ICMP traffic but no HTTP traffic: 2012, Palo Alto Networks, Inc. [7]

On ISP-B, we see the HTTP traffic in the same timeframe: Conclusion PBF can be a useful technique for directing traffic based on parameters like source IP address, port, application, etc. But careful consideration must be given when using it. PBF must consider the entire network and you need to carefully design symmetric routes. 2012, Palo Alto Networks, Inc. [8]