Re: nat issue
On Fri, Feb 04, 2011 at 03:54:20PM +0100, Pascal Hambourg wrote:
> 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=184.108.40.206 type=8 code=0 id=20486 src=220.127.116.11 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=18.104.22.168 type=8 code=0 id=62469 [UNREPLIED] src=22.214.171.124 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.
Thanks a lot! Good explanation. I completely forgot about bridge-nf-* vars.
- Re: nat issue
- From: Pascal Hambourg <firstname.lastname@example.org>