PBF is a nice way to split up traffic based on several arguments like the source address or the destination application (layer 7). For example: get http or https traffic through a cheap line like VDSL and everything else by the default fiber link (default ip route). That’s the theory and how it is designed to work.
In practice you may experience the following issue: Example: the application “ssh”, dedicated to be routed by PBF is not (always) being policy based forwarded. Instead it is sent via the default route.
Why is this happening?
The answer is simple if you’re aware of 2 things:
- How IP, especially TCP works.
- How the PaloAlto single path architecture and session processing sequence work.
TCP (a connection oriented protocol) requires a 3-Way-Handshake to setup. This furthermore means that a PBF-rule using an application signature will fail as the initial handshake of the connection (first part of the TCP 3-Way-Handshake) is not providing enough information to identify the application and to satisfy the PBF rule. This results in having the traffic been sent over the default route which finally looks like as policy based forwarding is not working.
How to deal with this?
Simply said: don’t use application signatures for tcp based applications in PBF rules. Use a service instead (like tcp.22 (tcp port 22)) for ssh.
And in the same time: this is not disadvantaging your security at all as you anyway need to define a corresponding security policy for allowing ssh to pass.
Why is this happening?
Because the routing decision based on PBF is happening before the security and nat rules are evaluated. If PBF “fails” the traffic is being sent via the default route.
Summarized:
- use services instead of application signatures in PBF rules
- use application signatures in security policy rules
Below is an example of PBF sending ssh and ssl traffic via ipsec tunnel.
Policy based forwarding rule:
Corresponding security rule:
Service group defining special ports used for ssh and ssl:
