This article explains why FBF does not work for FTP when ALG is enabled.

The parent session of ALG-based FTP traffic can be controlled according to the configured FBF, but the child session of ALG-based FTP traffic cannot be controlled according to the configured FBF. This issue is described in the example below.

Topology

Explanation

• FBF is used on the SRX1400 for a specific route.
• For traffic to FTP Server 192.168.2.120 , FBF is configured to look up the route from the routing-instance ( test1 ). Thus, all traffic to 192.168.2.120 is forwarded via the next-hop, 192.168.3.2 .
• For all other traffic, FBF is configured to use the default routing-instance: the default route with the next-hop, 192.168.3.3 .

FBF Configuration

root@SRX1400-A# show firewall
filter test1 {
    term 0 {
        from {
            destination-address {
                192.168.2.120/32;
            }
        }
        then {
            routing-instance test1;
        }
    }
    term 1 {
        then accept;
    }
}

Default Route for Routing-instance "test1"

root@SRX1400-A# show routing-instances
test1 {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 192.168.3.2;  <<<<< Default route in "test1" routing-instance
        }
    }
}

Default Route in "inet.0" and rip-group "rg-test1" for routing-instance "test1"

root@SRX1400-A# show routing-options
interface-routes {
    rib-group inet rg-test1;
}
static {
    route 0.0.0.0/0 next-hop 192.168.3.3;   <<<<< Default Route in "inet.0" routing-instance
}
rib-groups {
    rg-test1 {
        import-rib [ inet.0 test1.inet.0 ];
    }
}

FTP+ALG Enabled in the Same Environment

Explanation

• FTP ALG is also enabled in the same environment.
• SRX1400 receives FTP traffic to 192.168.2.120 from the FTP client.
• FBF works on the Parent session.
• The first packet of the Parent session is forwarded to 192.168.3.2 .
• But, when the FTP client starts the Child session in passive mode, SRX1400 forwards the first packet of the Child session to 192.168.3.3 using the default routing-instance.

The FTP Parent session and Child session go through different routes because they use different route tables to look up the route for the destination prefix, as explained below.

"flow traceoptions" of FTP Traffic

FTP parent session: vr_id is 5
   Apr  7 15:14:39 15:14:38.889531:CID-00:FPC-01:PIC-00:THREAD_ID-21:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.1.10, x_dst_ip 192.168.2.120, in ifp ge-0/0/0.0, out ifp N/A sp 2447, dp 21, ip_proto 6, tos 0

FTP child session: vr_id is 0
   Apr  7 15:14:40 15:14:40.027635:CID-00:FPC-01:PIC-00:THREAD_ID-22:RT:asl_usp_get_l3_out_ifp_out_tunnel ASL IPV4 out_ifp = ge-0/0/1.0 for dst:192.168.2.120 in vr_id:0

Explanation

• The FTP Parent session gets vr_id "5" (or test1.inet.0) according to FBF.
• The FTP Child session gets vr_id "0" (or inet.0) from the expected outgoing interface, as determined by the FTP parent session.
• Different routes are returned from these two VRs (see below).

Route table on SPU (FPC1 PIC0)

[flowd64]FPC1.PIC0(vty)# show route ip prefix 192.168.2.120

IPv4 Route Table 0, default.0, 0x0:
Destination   NH IP Addr      Type     NH ID Interface
------------  --------------- -------- ----- ---------
default       192.168.3.3     Unicast  577   RT-ifl 0 ge-0/0/1.0 ifl 73


IPv4 Route Table 5, test1.5, 0x0:
Destination   NH IP Addr      Type     NH ID Interface
------------  --------------- -------- ----- ---------
default       192.168.3.2     Unicast  578   RT-ifl 0 ge-0/0/1.0 ifl 73

SRX does not support the ALG+FBF scenario described above (the sharing of one outgoing interface).

Alternative solutions:

1. Disable ALG, then add the needed policy for the FTP Child session.

   OR

2. Change the design and avoid having one common outgoing interface.