Knowledge Search


×
 

[SRX] Filter Based Forwarding (FBF) does not work on SRX for client traffic when the session is initiated by server

  [KB27946] Show Article Properties


Summary:

This article explains a limitation of filter-based forwarding (FBF) on SRX devices, caused by stateful processing of traffic. There is no direct solution for this issue on the SRX.

A workaround is to configure traffic from certain clients to take an alternative path to the servers even when a session is initiated by a server.

Symptoms:
Filter-based forwarding (FBF) is used when a certain traffic is required to take an alternative route, instead of following the route in the main routing-table. For example, while servers are normally reachable via next-hop R1, a certain group of clients is required to reach the same servers via next-hop R2. In this case, a filter is used to match the clients by their source IP addresses, and their traffic is then processed by a separately created routing-instance which has R2 as the next-hop to the servers.

When configuring this feature on SRX devices, it works as expected for sessions initiated from clients to servers.
However, when a session is initiated from server to client, the client reply takes a normal route via R1, ignoring the alternative route dictated by FBF.
Cause:
This behavior is by design on SRX devices. When first packet of a session is processed, the SRX performs both forward and reverse route lookup. Thus at this stage it already determines the next-hop for the reply traffic.
When the reply traffic hits the FBF filter later, no route lookup is performed. Therefore the FBF is ignored.
Solution:

 To better understand the above explanation, note the following example network.

The clients from 10.0.0.0/8 network normally reach the servers from 20.0.0.0/8 network via the router R1. However, it is required that the management station 10.1.1.1 will reach the servers via the router R2.

The following filter is configured on the SRX:


[edit firewall family inet]
filter mgmt-fbf {
   term 10 {
      from {
         source-address {
            10.1.1.1/32;
         }
      }
      then {
         routing-instance mgmt-fbf-ri;
      }
   }
}

This filter is applied to the client-facing interface:


set interfaces ge-0/0/3.0 family inet filter input mgmt-fbf

The following alternative route is specified in the mgmt-fbf-ri:


[edit routing-instances]
mgmt-fbf-ri {
   instance-type forwarding;
   routing-options {
      static {
         route 20.0.0.0/8 next-hop 192.168.1.2;
      }
   }
}

Here 192.168.1.2 is the address of R2. The rest of the configuration is not provided in this article. Please refer to the FBF documentation for more details.

This is what happens when the management station 10.1.1.1 initiates a session to a server 20.1.1.1:

  1. The traffic arrives on SRX from interface ge-0/0/3 and hits the filter mgmt-fbf.

  2. The forward route lookup is performed in the context of routing-instance mgmt-fbf-ri, as dictated by the filter. The next-hop towards 20.1.1.1 is found to be 192.168.1.2 (R2).

  3. The reverse route lookup is performed for 10.1.1.1.    The next-hop towards 10.1.1.1 is found to be R0.

  4. The traffic is forwarded to 20.1.1.1 via R2 (192.168.1.2), as required.

  5. When the reply traffic arrives, it is forwarded back to 10.1.1.1 via R0.

However, this is what happens when the server 20.1.1.1 initiates a session to the management station 10.1.1.1:

  1. The traffic arrives on SRX from interface ge-0/0/5.

  2. The forward route lookup is performed in the context of main routing table. The next-hop towards 10.1.1.1 is found to be R0.

  3. The reverse route lookup is performed for 20.1.1.1.  The next-hop towards 20.1.1.1 is found to be R1, because this is what stated in the main routing table.

  4. The traffic is forwarded to 10.1.1.1 via R0.

  5. When the reply traffic arrives, it hits the filter mgmt-fbf.

However, no route lookup is performed at this stage, because the next-hop towards 20.1.1.1 is already determined to be R1 at step 3. Therefore, the reply traffic is forwarded to 20.1.1.1 via R1, thus ignoring the FBF.

There is no direct solution for this behavior on the SRX.

If the traffic from certain clients to servers should take an alternative path even when a session is initiated by a server, it is recommended to achieve that in other ways. For example, taking the above example further, we can configure an additional IP address on each server, for management purposes. That is, the management station will access the servers using the newly added IP addresses, and the servers will use these addresses when initiating sessions to the management station. The next-hop towards the new addresses will be R2, while the next-hop towards the old addresses will remain R1 (for the production traffic). In this way the required behavior will be achieved using conventional routing, without FBF. 


Related Links: