I've finally resolved this issue!
The problem is with iptables - specifically, the nat table.
The man page for iptables mentions that the nat table is only consulted
for what iptables thinks are new connections. The issue here is that
with bridging, packets make one trip through iptables on the bridge,
and then another trip on the actual interfaces (in my case, IN=eth1
OUT=eth0). The masquerading needs to be done on the *second* trip
through, though iptables will no longer consider it a new connection at
that point, and will simply skip the nat table.
The fix is to use the PREROUTING chain in the raw table with the
NOTRACK target:
iptables -t raw -I PREROUTING -i xenbr0 -j NOTRACK
This will have iptables ignore any packets on the bridge interface
itself, and if they wind up making the transistion to the physical
interfaces, they'll be treated as 'new' by iptables, which will then
send them through the nat table.
On Sat, Nov 25, 2006 at 03:57:30PM -0500, PinkFreud babbled thus:
> I've been beating my head against a wall for the past few hours trying
> to resolve this.
>
> The box I'm setting up Xen on is also the router for my network. It
> has two nics - eth0 (to the 'net), and eth1 (to my lan). I'm using
> bridging on the lan interface for Xen.
>
> When the bridge comes up, routing for the other systems on my lan goes
> to hell.
>
> According to iptables, any packets coming in peth1 are heading out
> vif0.0. This is *not* what I want!
>
> Nov 25 13:34:42 rivendell kernel: IN= OUT=xenbr0 PHYSIN=peth1 PHYSOUT=vif0.0
> SRC=192.168.1.3 DST=216.38.80.20 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40161 DF
> PROTO=TCP SPT=49361 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
>
> The routing table is simple - it uses the automatically created routes
> for the interfaces (192.168.0.0/23 goes to eth1, isp's network goes to
> eth0, and the default gw is my isp's, out eth0). I'm having trouble
> determining why packets originating from an interface on the bridge are
> simply ignoring the default route, though - 216.38.80.20 is most
> certainly not on my network, and kernel routing should be taking care
> of redirecting it out eth0, as per my routing table.
>
> This looks like a bug (can anyone tell me why a packet not destined for
> my local net, ignoring the default route is *not* a bug?). The
> question is - is it a Xen bug, or is it a bridge bug?
--
Mike Edwards | If this email address disappears,
Unsolicited advertisments to | assume it was spammed to death. To
this address are not welcome. | reach me in that case, s/-.*@/@/
"Our progress as a nation can be no swifter than our progress in education.
The human mind is our fundamental resource."
-- John F. Kennedy
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home