Blog

SRXs and policy based routing (aka FBF)

February 22, 2016 9:57 am

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.

Inetzero-blog-FBF-topology-1

For simplicity the policies were configured to allow all traffic between every zone pair.

The FBF related configuration was:

Inetzero-blog-FBF-image-01

Inetzero-blog-FBF-image-02

Inetzero-blog-FBF-image-03

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.

Inetzero-blog-FBF-image-04

Inetzero-blog-FBF-image-041

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:

Inetzero-blog-FBF-image-05

 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.

Inetzero-blog-FBF-image-04

Inetzero-blog-FBF-image-07

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.

Inetzero-blog-FBF-image-08

In this case the “PROXY-redirect” routing table looks as follows:

Inetzero-blog-FBF-image-09

Inetzero-blog-FBF-image-10

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”.

Inetzero-blog-FBF-image-11

Please note starting from Junos release 12.1×46 new flags were introduced in the flow traceoptions, such as “route”, “session”, etc. http://www.juniper.net/techpubs/en_US/junos12.1×46/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.

Inetzero-blog-FBF-image-12

Inetzero-blog-FBF-image-13

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)

Inetzero-blog-FBF-image-14

For brevity only relevant flow traceoptions messages are shown below:

Inetzero-blog-FBF-image-15

  • HTTP (protocol TCP and destination port 80)

Inetzero-blog-FBF-image-16

The relevant traceoptions messages:

Inetzero-blog-FBF-image-17

  • Protocol TCP and destination port 8080

Inetzero-blog-FBF-image-19

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.

Inetzero-blog-FBF-image-18

Inetzero-blog-FBF-image-20

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).

Inetzero-blog-FBF-topology-2

Inetzero-blog-FBF-image-21

Inetzero-blog-FBF-image-22

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).

Inetzero-blog-FBF-image-23

However, the connection fails again and traceoptions messages contain the same error as in the previous case.

Inetzero-blog-FBF-image-24

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.

Inetzero-blog-FBF-image-25

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”.

Inetzero-blog-FBF-topology-3

Inetzero-blog-FBF-image-26

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.

Inetzero-blog-FBF-image-27

Inetzero-blog-FBF-image-28

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.

Inetzero-blog-FBF-image-29

Inetzero-blog-FBF-image-30

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.

Richard Pracko

Richard Pracko

Richard Pracko lives in Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, and focused on the integration of Juniper Networks and Siemens products. In the beginning of 2009, he left Siemens on his own initiative, and became a full time instructor for and technical consultant, over a vast geographic area (EMEA and more).

More Posts

Categorised in:

3 Comments

  • Ed van Hout says:

    Even after more than a year still a relevant post because the Juniper SRX documentation contains little info on PBR.

  • bunyamin says:

    Hallo Richard,

    I have similar case about FBF. this like my case:
    The SRX have zone Server, Proxy1, Proxy2, and Internet. Proxy1 and 2 is same device (proxy1 interface to receive traffic from server and proxy2 to forward traffic to internet)
    FBF Case: From Server (172.17.1.0/24) destination to any Internet Zone (0/0) will be next hop to Proxy1. the traffic from Proxy1 will be forward to Internet via Proxy2. Assuming in proxy side has no issue about routing. and the ip address Server not change by proxy1 and proxy2. This like just transit traffic. I install the FBF into interface Server zone.

    The result:
    Traffic from Server1 has success to forward to Proxy1, but I have problem SRX didn’t receive any traffic from Proxy2 with Internet zone as last destination.

    Question: Is it possible my case about routing? because SRX forward and reiceive same ip/traffic in different zone which is zone Server and Proxy2. Do you have any advice about my case?

  • Maltar says:

    Hello,

    Having the exact issue that you described here.

    route lookup: dest-ip 10.255.129.11 orig ifp reth0.4092 output_ifp reth0.4080 orig-zone 17 out-zone 8 vsd 1

    Would the new feature enable-reverse-reroute resolve this issue? Is fairly new as its first appearance is 15.1X49-D123.

    https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/enable-reverse-reroute-edit-security-zones.html

Leave a Reply

Your email address will not be published. Required fields are marked *