This section discusses techniques and tools to manage fw3 and netfilter rules.
Almost all the issues with the firewall can gleaned from inspecting the netfilter tables and analyzing their relationships.
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
directives. Each directive is a complete
iptables command, runnable in a
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
-v: verbose, includes packet counts and physical interface name
-n: numeric output
-L: list rules
-S: print rules
-S arguments sort/format the output differently. The
option is equivalent to using the
You want to add a LOG target to see all HTTP traffic forwarded from your LAN to your WAN.
iptables -Lnto see the possible chains and rules,
zone_lan_forwardlooks like a good chain to add a new rule for LOG,
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?
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
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
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
/proc/sys/net/netfilter. This is almost never desirable.