This article provides information on how to process host inbound traffic, when the selective packet processing service is used. Host inbound traffic is any traffic directed to the f/w itself. This includes management traffic, routing protocol packets, and so on.

When selective packet processing service is used the host inbound traffic like ssh,telnet or J-web access to the box is seen to be failing. Is there any recommended way to process the host inbound traffic without completely disabling the selective packet processing service?

The recommended way to process host inbound traffic when the selective packet processing service is used, is to flow-process them. In other words, the firewall filter should be written in such a way that the traffic destined to the firewall itself should just be accepted and the rest of traffic allowed to bypass the flow module.

See The following example:

Host (10.1.1.2/24) --- (10.1.1.1/24) ge-0/0/0.0 SRX

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                filter {
                    input example_packet_filter;
                }
             address 10.1.1.1/24;
            }
        }
    }
}

firewall {
    family inet {
        filter example_packet_filter {
            term t1 {
                from {
                    destination-address 10.1.1.1/32;
                }
        then {
            accept;
        }
      term t2 {
          then {
              packet-mode;
              accept;
          }
      }
         }
     }
}

The host inbound traffic can also be packet-processed when the selective packet mode is used; however this is not recommended as it may pose potential security risks.
The above firewall filter is modified, as shown below, so that all ingress traffic bypasses the flow module.

firewall {
    family inet {
        filter example_packet_filter {
            term t1 {
                then {
                    packet-mode;
                    accept;
                }
            }
        }
    }
}

Special consideration must be taken for the TCP host inbound traffic, when they are packet-processed. When the TCP host inbound traffic (Telnet, SSH, BGP, and so on) is filtered, as it completely bypasses the flow engine, a flow session is not created.

However when the routing-engine sends SYN-ACK in response to the SYN packet, this is processed by the flow engine. All traffic generated by the f/w is always processed by flow engine. The SYN-ACK packet will be dropped as flow engine sees this as a new flow; yet the first packet is not a SYN packet.

In order to process TCP host inbound traffic, the TCP SYN check must be disabled.

security {
    flow {
        tcp-session {
            no-syn-check;
        }
    }
}
 

As shown below, the flow session indicates this session was initiated by 10.1.1.1/23; although this is not the case. The initial SYN packet from host (10.1.1.2/57221) completely bypassed the flow engine; so as seen by the flow module, the first packet processed for this session is generated by the f/w (10.1.1.1/23).

You can also see the reverse wing is created to allow traffic in opposite direction; however the packet counter will never increment as all traffic in that direction will bypass the flow module.

Session ID: 303, Policy name: self-traffic-policy/1, Timeout: 1800, Valid
In: 10.1.1.1/23 --> 10.1.1.2/57221;tcp, If: .local..0, Pkts: 85, Bytes: 7315
Out: 10.1.1.2/57221 --> 10.1.1.1/23;tcp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0