Netfilter Management

This section discusses techniques and tools to manage fw3, fw4 and netfilter rules.

Almost all the issues with the firewall can be gleaned from inspecting the netfilter tables and analyzing their relationships.

The fw4 application is the nftables frontend used in OpenWrt.

fw4 print dumps the nftables configuration that is built by fw4 and passed to nftables. It contains slightly higher-level code than the raw nftables state: fw4 uses variables, include files...

When debugging rules emitted by fw4, this is a good starting point.

nft list ruleset dumps the full nftables configuration from the kernel. This dump mixes data from different sources:

• rules generated by fw4
• rules included from external files (/etc/nftables.d/*.nft or /usr/share/nftables.d/)
• rules added manually through the nft command

Somethings, the nftables ruleset may exhibit unexpected behaviour, such as a packet being dropped while it should not. In that case, tracing can help: it allows to print all rules traversed by a given packet.

See https://wiki.nftables.org/wiki-nftables/index.php/Ruleset_debug/tracing for the full explanation. The following is simply an adaptation of this wiki page to the fw4 ruleset.

You first need to add a tracing chain:

nft add chain inet fw4 trace_chain { type filter hook prerouting priority -301\; }

Then add one or more rules to match packets you are interested in, such as:

nft add rule inet fw4 trace_chain ip saddr 203.0.113.42 meta nftrace set 1
nft add rule inet fw4 trace_chain udp dport 50014 meta nftrace set 1

Finally, you can look at the result of the trace (ideally in another terminal):

nft monitor trace

Beware, each traced packet will generate a huge amount of output!

To stop the tracing, remove the chain:

nft delete chain inet fw4 trace_chain

The fw3 application is a good command line interface to see all the netfilter rules.

fw3 print dumps all the netfilter rules to stdout as a set of iptables directives. Each directive is a complete iptables command, runnable in a shell.

Additionally, the directives are organized hierarchically so the entire dump could be run as a script to recreate the firewall rule set.

fw3 print is the main utility to inspect iptable rules. Additionally the iptable command can be used to sort the rules differently and retrieve packet counts for matching rules. There are a number of arguments but the two most useful examples are:

iptables -t <table> -vnL
iptables -t <table> -vS

where

• <table> is one of: filter (default), nat, mangle
• -v: verbose, includes packet counts and physical interface name
• -n: numeric output
• -L: list rules
• -S: print rules

The -L and -S arguments sort/format the output differently. The -S option is equivalent to using the iptable-save command.

• rules created by fw3 have “!fw3”

You want to add a LOG target to see all HTTP traffic forwarded from your LAN to your WAN.

• Run fw3 or iptables -Ln to see the possible chains and rules,
• zone_lan_forward looks like a good chain to add a new rule for LOG,
• in /etc/firewall.user add iptables -A zone_lan_forward --dport 80 -j LOG --log-prefix “HTTP-LAN-ALL:”

Now reload the rules and send a curl request from a LAN station, check the local syslog and only SYN/FIN packets are logged. The rule is sort of working but where are all the packets between the SYN setup and FIN release?

Use iptables -nL to inspect the FORWARD chain:

Chain FORWARD (policy DROP)
num  target     prot opt source               destination         
1    forwarding_rule  all  --  0.0.0.0/0            0.0.0.0/0            /* !fw3: user chain for forwarding */
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* !fw3 */
3    zone_lan_forward  all  --  0.0.0.0/0            0.0.0.0/0            /* !fw3 */
4    zone_wan_forward  all  --  0.0.0.0/0            0.0.0.0/0            /* !fw3 */
5    reject     all  --  0.0.0.0/0            0.0.0.0/0            /* !fw3 */

From this one can see that the zone_lan_forward chain is only tested when a connection is being initialized or torn down. For ESTABLISHED connections, the ACCEPT in rule #2 ends the chain traversal.

To fix this, append your LOG rule to the forwarding_rule chain.

Many netfilter features, especially NAT, depend on the nf_conntrack modules to track IP connections between the WAN-side and the LAN-side. Access to the conntrack tables can be invaluable when debugging traffic rules. The kernel presents the table through the procfs filesystem at /proc/net/nf_conntrack.

Here is a typical conntrack entry:

ipv4     2 tcp      6 4088 ESTABLISHED src=192.168.3.171 dst=192.168.10.175 sport=33284 dport=22 packets=24 bytes=1248 src=192.168.10.175 dst=192.168.3.171 sport=22 dport=33284 packets=24 bytes=1248 [ASSURED] mark=0 use=2

This is a ipv4 tcp session on port=22 (SSH). It shows a connection from STA1 to STA2 and then the reverse mapping.

The nf_conntrack parameters can be tuned using parameters in the sysfs filesystem under /proc/sys/net/netfilter. This is almost never desirable.