Record of iptables mismatch rules in Ubuntu16.04 Network Bridge mode

A few days ago, you needed to verify a feature of iptables in the high Linux kernel because of your work needs. So I built an experimental environment using Ubuntu16.04 (the kernel version is 4.13.0). Previous use of CentOS6.5 more (kernel version is 2.6.35), Ubuntu used less. When the environment was set up, a strange spot was found immediately.

root@ubuntu:/home/liu# IPTABLES-NVL 
Chain INPUT (policy ACCEPT 228 packets, 23310 bytes)
 pkts bytes target     p Rot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target< C8/>prot opt     in out     source               destination         

Chain OUTPUT (Policy ACCEPT
 282 packets, 55168 bytes) Pkts bytes Target     prot opt in     out     source               destination         

Bridge brg0 under the two interface enp2s6 and ENP2S7, two PCs, I ping another pc from one PC, the result of using Iptables view the filter table forward chain does not have any packet matching (policy ACCEPT 0 Packets, 0 bytes). Obviously, the rules that are added to the forward chain are not matched. This is so strange.

Normally, the packets forwarded by the Network Bridge also match the rules of the forward chain (if there are no rules, the default accept policy is matched). So I switched back to CentOS6.5 and found that the forward chain of the filter table was counted. Is there a problem with iptables? I recompile a iptables directly, found that still, it seems that there is no relationship with Iptables.

Search the Internet Some, did not find a similar problem. have to position themselves.

My positioning process is as follows:

Direct Search Linux4.13 kernel version of the source code, look for "Nf_inet_forward", immediately find the NET\BRIDGE\BR_NETFILTER_HOOKS.C file br_nf_forward_ip functions are as follows:

	Nf_hook (PF, Nf_inet_forward, State->net, NULL, SKB,
		Brnf_get_logical_dev (SKB, State->in),
		parent,	br_nf_forward_finish);

The hook function registered with the Nf_inet_forward Hook point is invoked. One of the hook functions traverses the forward chain rule of the filter table. Now it looks like the bridge forwarding process didn't come here. What to do. Add the print chant. Add a print at the end, then recompile the kernel module and discover that the build Net/bridge/br_netfilter.ko will be recompiled. This ko is very strange, lsmod see incredibly did not load this KO, so directly put this KO load, immediately normal.

root@ubuntu:/home/liu# IPTABLES-NVL 
Chain INPUT (Policy ACCEPT 15496 packets, 3400K bytes)
 pkts bytes target
  
   prot opt in     out     source               destination         

Chain FORWARD (Policy ACCEPT 207 packets, 12474 bytes)
 pkts Bytes Target     prot opt     in out     source               destination         

Chain OUTPUT (Policy ACCEPT 14546 packets, 17M bytes)
 pkts bytes target     prot opt in     out     source               destination         
  

What a ghost this Br_netfilter.ko is. Checked, the NetFilter ebtables project group website impressively flashes the following hint:

Since Linux kernel 3.18-rc1, you are have to modprobebr_netfilter to enable Bridge-netfilter.

From the LINUX3.18-RC1 kernel version, you must manually load the Br_netfilter.ko to start the Bridge-netfilter feature, which is described in detail in the official website:

{Ip,ip6,arp}tables can filter bridged ipv4/ipv6/arppackets, even when encapsulated into an 802.1Q VLAN or PPPoE header. Thisenables the functionality of a stateful transparent firewall.

After loading br_netfilter this KO, iptables can filter the Network Bridge processing packets, can use the/proc/sys/net/bridge/bridge-nf-call-iptables value to control whether Iptables can "see" Network Bridge processing of packets. The default system does not load this KO when it is started, so that iptables is not able to see the Network Bridge processing of these packets. It will not match any of the rules in any iptables.

Record this article, hope to encounter the same problem friends can be less detours.