Devices typically use the packet's destination IP address for routing (or forwarding) table lookup. Sometimes using the destination IP address is not sufficient because other aspects, such as the protocol and port numbers, need to be considered as well. For instance all traffic should has to be send out via the uplink connection except HTTP that has to be directed to a transparent proxy. Another example can be directing traffic only from specific hosts to a deep inspection device for closer analysis while other traffic bypasses the inspection. The capability to consider other aspects and not just destination IP address in forwarding decisions is called policy based routing (PBR). Some vendors, however call it differently. On Junos devices the name is filter based forwarding (FBF), because it utilizes firewall filters.
To be more accurate, FBF involves firewall filters (action “routing-instance”) and routing-instances (type “forwarding”). The basic idea is to have the device perform the forwarding lookup in a different forwarding table than it would normally use. The mentioned firewall filter action “routing-instance” does just that. The lookup for traffic matching the term's criteria takes place in the referenced routing instance and not in the instance where the packet arrived.
The FBF influence on the forwarding decision can sometimes result in asymmetric routing which the security devices are not very fond of.
Let us go through few examples and examine how the FBF influences the security processing on SRXs.
The image below displays the topology.
For simplicity the policies were configured to allow all traffic between every zone pair.
The FBF related configuration was:
In this state the routing instance “PROXY-redirect” exists. But the routing table (and therefore also the forwarding table) is empty even though a static route is defined. The reason is lack of knowledge how to reach the next hop of the default route within the “PROXY-redirect” routing instance.
To solve this problem sharing interface routes between routing instances is needed. One approach to accomplish this is based on RIB groups. Another alternative is the use of the “instance-import” parameter.
Configuration for RIB group approach:
As a result the routing table of the “PROXY-redirect” instance is populated with the interface routes (both – direct and local) and the default route.
Routing policies can be applied through the “import-policy” statement within the RIB group to fine tune the route sharing if needed. This greatly improves the flexibility.
The alternative – the “instance-import” statement – is solely based on routing policies. The “instance-import” parameter is configured in the routing instance where the routes should be inserted into. Therefore it is advisable to include the source instance name in the policy criteria as well to avoid sharing of undesired routes. Typically a term rejecting everything is placed at the end of the policy because routes not explicitly denied are accepted.
In this case the “PROXY-redirect” routing table looks as follows:
Now let's have a short look at the security processing when FBF is in place. The topology and the FBF configuration remained the same. Only the flow traceoptions were enabled with the flags “basic-datapath” and “route”.
Please note starting from Junos release 12.1x46 new flags were introduced in the flow traceoptions, such as “route”, “session”, etc. http://www.juniper.net/techpubs/en_US/junos12.1x46/topics/reference/configuration-statement/security-edit-traceoptions-flow.html
The flow traceoptions messages contain sometimes only the internal IDs of the routing-instances and zones. For reference and better understanding the routing-instances, zones and their internal IDs are listed in the outputs below.
For testing the connections were initiated from the host1 (172.17.1.2) to the destination 1.1.1.1
- telnet (protocol TCP and destination port 23)
For brevity only relevant flow traceoptions messages are shown below:
- HTTP (protocol TCP and destination port 80)
The relevant traceoptions messages:
- Protocol TCP and destination port 8080
In this case the traceoptions messages are almost the same as for the previous case - HTTP connection.
As seen from the examples FBF takes place for the TCP connections to the destination ports 80 and 8080 (exactly according to the firewall filter matching criteria). The FBF changes the outgoing interface and zone and essentially influences which policies are going to be evaluated for the traffic.
For the connections initiated in the opposite direction (from 1.1.1.1 to the host1 172.17.1.2) it is different story. Here a problem exists if packets arrive on the ge-0/0/3.0 interface instead of the ge-0/0/2.0. Even though the SRX creates a session the traffic in the response flow is denied. The traceoptions messages (shown after the session output) reveal the reason – zone mismatch in the routing lookup for the reverse flow. I.e. the traffic arrives on different interface than expected based on routing.
Now the question is: Does the SRX consider the firewall filter only for the initiating flow or for the reverse flow as well? In other words, can the FBF be used to influence the routing for the reverse flow in the session to fix the problem above?
Let's adjust our scenario and test it.
The firewall filter attached to the ge-0/0/1.0 was modified to send also all TCP traffic to host 1.1.1.1 through the ge-0/0/3.0 interface (same interface as the TCP connections to port 80 and 8080).
The connections from 1.1.1.1 to host1 (172.17.1.2):
- entering the SRX through the ge-0/0/3.0 interface. The modified filter attached to ge-0/0/1.0 directs the traffic out of the same interface as it enters (ge-0/0/3.0).
However, the connection fails again and traceoptions messages contain the same error as in the previous case.
The conclusion based on the experienced results: SRX disregards firewall filters attached to interfaces when doing routing lookup for the reverse flow.
Another situation with unsuccessful connection is when the reverse flow traffic arrives on a different interface than the initiating flow is send out. This is a typical result of asymmetric routing. For example the traffic is leaving the device through ge-0/0/3.0 but the response packets (reverse flow) arrive on another interface, let's say ge-0/0/2.0.
To have SRX accept and permit such connections both interfaces – the one where traffic arrives and the expected one – must be in the same zone.
In our case this involves the ge-0/0/2.0 and ge-0/0/3.0 interfaces. Both were placed in the zone “untrust”.
After the change sessions from the host 1.1.1.1 arriving on the ge-0/0/3.0 interface are allowed. Please note the session output contains the ge-0/0/2.0 interface as the incoming one.
Similarly the sessions from host1 (172.17.1.2) to host 1.1.1.1 where the response traffic arrives on ge-0/0/2.0 are successful. Here please note the session output contains the interface used to send out the packets – ge-0/0/3.0.
Conclusion
This article focused on the filter based forwarding on SRXs, functionality known with other vendors as policy based routing. It allows to make forwarding decisions based on other aspects than just destination address which greatly increases the routing flexibility. On the other hand it can lead to higher network complexity and sometimes even result in asymmetric routing. The latter one can be potentially dangerous when firewalls are present in the network, because it can end up with denying traffic is not handled correctly. Couple examples of SRX security traffic processing that involves FBF were presented in this text. Few things to keep in mind and watch out for were pointed out as well.
