> For the complete documentation index, see [llms.txt](https://jncia-workbook.gitbook.io/workbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jncia-workbook.gitbook.io/workbook/junos-firewall-filters/5-multiple-filters.md).

# 5) Multiple Filters

### Pre-Work

Load the config called **multiple.filters.tshoot.cfg** using the **load\_config\_on\_nodes.py** script.

```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename multiple.filters.cfg
```

### Lab

An input filter is present on R2's `ge-0/0/0` that prevents access to infrastructure addresses.

Block pings to `3.3.3.3/32` as well, inbound on `ge-0/0/0`, but **do not edit the existing input filter.**

### Answer

<details>

<summary>Expand to reveal</summary>

Configure a second filter, and apply both filters to the interface using `input-list`.

```
edit firewall family inet filter ge-0/0/0_customer_v4
set term block_r3_loopback from destination-address 3.3.3.3/32
set term block_r3_loopback then discard
set term allow_all then accept

top
delete firewall family inet filter infra_filter_v4 term allow_all
delete interfaces ge-0/0/0.0 family inet filter input
set interfaces ge-0/0/0.0 family inet filter input-list [ infra_filter_v4 ge-0/0/0_customer_v4 ]
```

</details>

### Explanation

<details>

<summary>Expand to reveal</summary>

It is quite common to have an "infrastructure ACL" that you want applied to all interfaces, and also a separate "customer ACL" which has specific policies for a particular interface. It would be extremely difficult to manage a single ACL per interface that contains both the infrastructure rules and the customer rules. You would end up duplicating the infrastructure rules among many different filters, each of which would need to be individually updated if you want to make a change to infrastructure rules.

\
On Junos, we can chain together ACLs by using the `input-list` or `output-list` configuration on an interface. The filters are applied in the order you configure them in.

```
set interfaces ge-0/0/0.0 family inet filter input-list [ infra_filter_v4 ge-0/0/0_customer_v4 ]
```

\
In our lab, the infrastructure filter is applied first. If the packet passes this filter, then the customer filter is applied. If the packet passes the customer filter, then the packet is accepted.

\
Note that for this to work, all filters in the list, except the last one, cannot have an explicit accept-all term. Otherwise traffic will hit this term and stop processing. Imagine if all terms of the firewall filters were combined into one single filter. The accept-all term in an earlier filter would shadow all subsequent rules. For this reason we have to delete the existing accept-all term on the infra filter:

```
delete firewall family inet filter infra_filter_v4 term allow_all
```

\
There is also a second method to chain filters together. You can apply one filter inside another using `set term <name> filter <filter name>`. This allows you to nest filters inside each other. This would also be an acceptable solution to this lab.

```
edit firewall family inet filter ge-0/0/0_customer_v4
set term apply_infra_filter filter infra_filter_v4
set term block_r3_loopback from destination-address 3.3.3.3/32
set term block_r3_loopback then discard
set term allow_all then accept

top
delete firewall family inet filter infra_filter_v4 term allow_all
set interfaces ge-0/0/0.0 family inet filter input ge-0/0/0_customer_v4
```

</details>

### Further Reading

<https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/firewall-filter-option-multiple-listed-overview.html>

<https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/example/firewall-filter-option-multiple-nested-example.html>