> 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/4-troubleshooting-filters.md).
# 4) Troubleshooting Filters
### Pre-Work
Load the config called **filter.tshoot.cfg** using the **load\_config\_on\_nodes.py** script.
```
python3 load_config_on_nodes.py --lab_dir three-routers --config_filename filter.tshoot.cfg
```
### Lab
The filter from the previous lab is already configured on R2 again.
This time, an administrator has added a term called `capture_10-8` at the top of the v4 firewall filter to log traffic with a destination address in 10/8. The administrator does not want to affect how rules are processed, they just want to log traffic temporarily.
However, when they added this term, they found that they could ping 10.1.2.2 from R1.
Explain the problem and find a solution.
### Answer
Expand to reveal
The problem is that non-terminating actions have a default terminating action of `accept`. Therefore, traffic hitting the new term called `capture_10-8` will be accepted and processing will stop. This new term has effectively shadowed the `block_local_address` term. To prevent this, we must add `then next term`.
```
set firewall family inet filter ge-0/0/0_filter_in_v4 term capture_10-8 then next term
```
\
You should see that the filter is now correct, and pings no longer work:
```
admin@R1> ping 10.1.2.2
PING 10.1.2.2 (10.1.2.2): 56 data bytes
^C
--- 10.1.2.2 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
```
### Explanation
Expand to reveal
Take a look at the config that is preconfigured. The `capture_10-8` term at the top has a single action, which is `log`:
```
admin@R2> show configuration firewall family inet
filter ge-0/0/0_filter_in_v4 {
term capture_10-8 {
from {
destination-address {
10.0.0.0/8;
}
}
then log; <-------------------------------
}
term allow_ospf {
from {
protocol ospf;
}
then accept;
}
term block_local_address {
from {
destination-address {
10.1.2.2/32;
}
}
then {
discard;
}
}
term allow_all {
then accept;
}
}
```
\
Non-terminating actions have an implicit `accept` action when no explicit terminating action is configured on the term. This causes rule shadowing. To prevent this, we must add a `next term` action in addition to the `log` action.
```
admin@R2> show configuration firewall family inet
filter ge-0/0/0_filter_in_v4 {
term capture_10-8 {
from {
destination-address {
10.0.0.0/8;
}
}
then {
log;
next term; <---------------------
}
}
term allow_ospf {
from {
protocol ospf;
}
then accept;
}
term block_local_address {
from {
destination-address {
10.1.2.2/32;
}
}
then {
discard;
}
}
term allow_all {
then accept;
}
}
```
> Firewall filters support different sets of nonterminating actions for each protocol family, which include an implicit accept action. In this context, *nonterminating* means that other actions can follow these actions whereas no other actions can follow a *terminating* action. As such, you cannot configure the `next term` action with a *terminating* action in the same filter term. You can, however, configure the `next term` action with another *nonterminating* action in the same filter term.
### Further Reading
> Nonterminating actions carry the implicit terminating action of accept.\
> When applied to a firewall filter term without an explicit terminating\
> action, the default action of accept will be used. This could cause\
> unintended packet processing side effects if you are just looking to\
> sample or log a packet. To avoid the implicit accept action, use the next\
> term action to allow further processing of the packets within the\
> firewall filter.