The diagram below outlines the SRX flow module and order of events. Firewall filters are referenced as 'per packet filter' in this diagram. This diagram gives a good visual representation of where firewall filters are applied in the sequence of events.
Firewall Filters are created consisting of terms. Terms are processed in order. The firewall filter has a default-deny/drop action at the end.
Terms consist of from(match) and then(action) statements.
From statements specify parameters to match traffic. The match options vary based on protocol family.
Then statements specify actions to take if the from condition is matched. This actions vary based on protocol family.
1. Create firewall filter with term(s).
2. Apply filter to logical interface for a specific direction.
*remember last term must be accept or all traffic will be dropped*
It should be noted that when configuring firewall filters directly under the [edit firewall filter name] stanza that inet (IPv4) firewall filters are actually created. Inet (IPv4) firewall filters can also be configured under [edit firewall family inet filter name]. The reason for this (from what I could find) is that older versions of Junos originally only supported the protocol family inet firewall filters and did not have the need to specify protocol family. This method of allowing both options allows for backward compatibility with legacy configurations.
Firewall filters configured for a specific protocol family can only be configured on interfaces which are configured under the same protocol family. For example you cannot apply a 'family inet' firewall filter to an interface configured as 'family bridge'.
Logging is important whenever action is taken on traffic, and firewall filters are no exception. There are two logging actions that can be defined under the 'then' statement within a firewall filter term. The first is 'log', in this statement events are generated and stored on the packet forwarding engine (PFE) and not the control plane (RE). The second is 'syslog', with this statement configured events are generated and sent to the control plane (RE) for processing. They can be send to external syslog servers or written to local files with the appropriate syslog configuration.
Applications & Examples
The following basic topology will be used for the following examples.
1. Block specific Protocol/IP Address
This example outlines how specific protocols and/or IP prefixes can be blocked on the ingress of an interface. This could be useful for purging unwanted traffic before it is processed by the flow module. In this specific example I set up a firewall filter with two terms. The first term is set to match icmp-echo-request traffic destine for the IP address of 22.214.171.124. The second term is to pass (or accept) all other traffic. Without the second term all traffic not matching the first term would be dropped. Lastly the filter is applied to an interface on the inbound direction. The screenshot below outlines the commands.
In the above configuration example 'log' was configured under the then statement for term BLOCK8888. This ensures that events are logged on the PFE. To display these events the command 'show firewall log' can be used. The screenshot below displays the output.
As mentioned above there is a second logging method of syslog. The screenshot below modifies the example so that term BLOCK8888 is configured to log the syslog method. See the screenshot below for command details.
Syslog files can now be created so that firewall filter log events are written to local files. The screenshot below outlines the commands to create two log files. The first is a file which is created with a match statement. In this case we can match on firewall filter events by matching 'PFE-FW'. The second log file uses a pre-canned definition of 'firewall' which will also log firewall filter events. Although it is not done in this example, we could also specific external syslog servers to have these events send to an external syslog server.
The command 'show log logfilename' can be used to display the contents of the log file. The immediate screenshot below displays the log file where a match statement is specified. The second screenshot displays the log file where the predefined syslog firewall log was used.
2. Bypass Flow Module
This example outlines how identified traffic can be set to bypass the flow module. The SRX does allow you to enable packet mode on the entire device (making it function like a traditional router). If you need to apply this kind of treatment for only certain traffic then using firewall filters with the action of 'packet-mode' will allow you to do this. In this specific example I have created a firewall filter to identify traffic from the subnet 192.168.1.0/24 to the IP address of 192.168.1.1 (interface of the SRX). The then statement is 'packet-mode' meaning traffic matching this statement will be processed as if the device was a router (no flow module processing).
**Keep in mind that if using firewall filters to bypass flow module for transit traffic, firewall filters will be needed in both directions.**
The command 'show log logfilename' can be used to verify that traffic is matched and therefore bypassing the flow module.
We can also confirm the flow management is bypassed by accessing the JWeb management page. The screenshot following this one displays the security zone configuration. You will notice that (https) is not listed under host-inbound-traffic. This would be that access to the JWeb page on https should not be allowed. In this case it is as the traffic is bypassing the flow module.
Firewall filters offer a very flexible and light-weight method of controlling traffic. The conditions traffic can be matched on are very powerful and extensive. Some tasks would be better done in the security policy, others with firewall filters. Overall it is another feature to leverage in the SRX product when needed.