| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] iptables and state matches (established, related)
On Thu, May 03, 2007 at 09:04:53AM +0200, Marc Patino G?mez wrote:
> I have the same problem, and also
>
> echo "0" >/proc/sys/net/bridge/bridge-nf-call-iptables
>
> solves it. I don't known the reason, so I will read some doc about it.
Its a pretty confusing bit of iptables. Basically if you have that
setting at 0, then traffic going between 2 interfaces in a bridge
will not hit iptables. If you have it set to 1, then it'll have a
normal set of iptables rules applied. There are use cases for both
possible settings.
If you're using the regular network-bridge, with it set to zero
you'll see
Traffic: Guest -> Google
------------------------
Nada
Traffic: Guest -> Host
----------------------
Out:
NAT-PREROUTING IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132
INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132
Back:
OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120
Traffic: Host -> Guest
----------------------
Out:
NAT-OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120
OUTPUT IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120
NAT-POSTROUTING IN= OUT=eth1 SRC=192.168.254.132 DST=192.168.254.120
Back:
INPUT IN=eth1 OUT= SRC=192.168.254.120 DST=192.168.254.132
Now with bridge-nf-call-iptables set to 1
Traffic: Guest -> Google
------------------------
Out:
NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0
SRC=192.168.254.120 DST=64.233.167.99
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1
SRC=192.168.254.120 DST=64.233.167.99
NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=peth1
SRC=192.168.254.120 DST=64.233.167.99
Back:
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=peth1 PHYSOUT=vif2.0
SRC=64.233.167.99 DST=192.168.254.120
Traffic: Guest -> Host
----------------------
Out:
NAT-PREROUTING IN=xenbr1 OUT= PHYSIN=vif2.0
SRC=192.168.254.120 DST=192.168.254.132
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1
SRC=192.168.254.120 DST=192.168.254.132
NAT-POSTROUTING IN= OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1
SRC=192.168.254.120 DST=192.168.254.132
INPUT IN=eth1 OUT=
SRC=192.168.254.120 DST=192.168.254.132
Back:
OUTPUT IN= OUT=eth1
SRC=192.168.254.132 DST=192.168.254.120
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0
SRC=192.168.254.132 DST=192.168.254.120
Traffic: Host -> Guest
----------------------
Out:
NAT-OUTPUT IN= OUT=eth1
SRC=192.168.254.132 DST=192.168.254.120
OUTPUT IN= OUT=eth1
SRC=192.168.254.132 DST=192.168.254.120
NAT-POSTROUTING IN= OUT=eth1
SRC=192.168.254.132 DST=192.168.254.120
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif0.1 PHYSOUT=vif2.0
SRC=192.168.254.132 DST=192.168.254.120
Back:
FORWARD IN=xenbr1 OUT=xenbr1 PHYSIN=vif2.0 PHYSOUT=vif0.1
SRC=192.168.254.120 DST=192.168.254.132
INPUT IN=eth1 OUT=
SRC=192.168.254.120 DST=192.168.254.132
So you're changing what set of iptables chains get traversed
by toggling that setting.
> John Hannfield wrote:
> >This is a known problem with Xen 3.0.x and iptables connection tracking.
> >Connection tracking and state filtering only works as long as xen is
> >not running.
> >Try doing this:
> >
> >echo "0" >/proc/sys/net/bridge/bridge-nf-call-iptables
> >
> >That fixed it for me.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home