[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nat issue



Hello,

Oleg a écrit :
> 
> INET  <-- (eth0)[host](tap0) <-- [kvm1] <-- [kvm2]
> 
> host:~# iptables-save 
> # Generated by iptables-save v1.4.10 on Thu Feb  3 15:53:45 2011
> *nat
> :PREROUTING ACCEPT [158:19117]
> :INPUT ACCEPT [142:17947]
> :OUTPUT ACCEPT [1273:77619]
> :POSTROUTING ACCEPT [23:1515]
> -A POSTROUTING -o eth0 -j MASQUERADE 
[...]
> host:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.5a2372d4412f       no              tap2
>                                                         tap4
>   kvm1 link with host through tap0 and with kvm2 through tap2(br0). kvm2 link
> with kvm1 through tap4(br0).
[...]
>   When I ping from kvm1 everything is ok:
> 
> host:~# grep 192.168.100.1 /proc/net/ip_conntrack
> icmp     1 19 src=192.168.100.1 dst=8.8.8.8 type=8 code=0 id=20486 src=8.8.8.8 dst=192.168.0.178 type=0 code=0 id=20486 mark=0 secmark=0 use=2
> 
>   But when I ping from kvm2 packets is not nated:
> 
> host:~# grep 192.168.200.2 /proc/net/ip_conntrack
> icmp     1 22 src=192.168.200.2 dst=8.8.8.8 type=8 code=0 id=62469 [UNREPLIED] src=8.8.8.8 dst=192.168.200.2 type=0 code=0 id=62469 mark=0 secmark=0 use=2
> 
>   I use accounting rules and see that packets from 192.168.200.2 doesn't reach
> nat POSTROUTING chain:
[...]
>   Any ideas?

Yes, one : just another case of undesirable interaction between bridge
and netfilter (aka bridge-netfilter).

If the kernel was built with CONFIG_BRIDGE_NETFILTER=y (Debian kernels
are) and sysctl net.bridge.bridge-nf-call-iptables=1 (this is the kernel
default), then IP packets going through a bridge are passed to iptables
chains, as described in Documentation/networking/ip-sysctl.txt. This is
a nice feature when you want to set up a filtering bridge.

Granted, you don't have any iptables rules related to the bridge.
Indeed, but the description in ip-sysctl.txt is incomplete.
Bridge-netfilter does not actually pass packets to iptables chains but
to netfilter hooks, which in turn passes them to iptables chains - but
not only : it also passes them to conntrack (connection tracking). And
remember that NAT rules can be applied to a connection only the first
time it is seen by conntrack. Here the first time conntrack sees the
ping is when it goes through the bridge from tap4 to tap2. And this
time, there is no NAT operation.

Setting sysctl net.bridge.bridge-nf-call-iptables=0 to disable passing
bridged packets to netfilter shouldf fix the problem.


Reply to: