From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francois Goudal Subject: Re: NAT issue on a machine with both routing and bridging. Date: Mon, 23 Jun 2008 18:00:57 +0200 Message-ID: <485FC8B9.1010804@satcom1.com> References: <485FB19D.9080908@satcom1.com> <485FBB02.9090901@riverviewtech.net> <485FC07D.6060306@satcom1.com> <485FC5B4.8060608@riverviewtech.net> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <485FC5B4.8060608@riverviewtech.net> Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="iso-8859-1"; format="flowed" To: Grant Taylor Cc: Mail List - Netfilter Grant Taylor a =E9crit : > On 06/23/08 10:25, Francois Goudal wrote: >> Yes, Host C is the Dom0 and Host B is a DomU here. >=20 > *nod* >=20 >> bridge name bridge id STP enabled interfaces >> br0 8000.00304883f91f no eth1 >> vif1.0 >> br1 8000.c6eabf59b7a0 no vif1.1 >> br2 8000.00304883f91e no eth0 >> >> This looks like the ASCII-art I did, I double checked all this, I=20 >> don't think the problem comes from the bridge configuration, but you= =20 >> will probably tell me if you can see sth wrong here :-) >=20 > I don't see any thing obviously wrong. At least the output of brctl=20 > seems to line up with your ASCII art. >=20 Ok, at least this is good :-) >> I don't understand your question. I want them to be masqueraded, but= =20 >> the fact is that I can't get them masqueraded when they come from a=20 >> machine connected to eth1 on the Dom0. But they are masqueraded when= =20 >> they come from the DomU. But I don't see any reason for that=20 >> difference. On the Dom0, the eth1 interface is linked with a bridge = to=20 >> one interface of the DomU but no IP addresses are set (on eth1 itsel= f,=20 >> on the bridge interface it belongs to, and on the Xen backend=20 >> interface which is in the bridge) so the traffic has to go through t= he=20 >> DomU, so now, why is it working with the DomU itself but not with th= e=20 >> hosts connected on eth1, I have no idea :-/ >=20 > Why are you not masquerading the packets that leave br2 in Host C (Do= m0)? >=20 > hostC# iptables -t nat -A POSTROUTING -o br2 -j MASQUERADE >=20 > Not having run Xen my self, I'm not sure how the br# lines up with=20 > xenbr# so I can't say for sure. >=20 > What does iptables-save on Host C (Dom0) have to say? >=20 I'm sorry, this is my mistake, you should replace xenbr0 by br2 in all=20 what I said, this is because I have done the setup again on another=20 machine and I didn't name everything exactly the same. Anyway, iptables-save returns : # Generated by iptables-save v1.3.6 on Mon Jun 23 19:21:32 2008 *raw :PREROUTING ACCEPT [38549:54443202] :OUTPUT ACCEPT [21429:1190521] COMMIT # Completed on Mon Jun 23 19:21:32 2008 # Generated by iptables-save v1.3.6 on Mon Jun 23 19:21:32 2008 *nat :PREROUTING ACCEPT [3560:445076] :POSTROUTING ACCEPT [520:47639] :OUTPUT ACCEPT [15:913] -A POSTROUTING -o br2 -j MASQUERADE COMMIT # Completed on Mon Jun 23 19:21:32 2008 # Generated by iptables-save v1.3.6 on Mon Jun 23 19:21:32 2008 *filter :INPUT ACCEPT [37185:54270101] :FORWARD ACCEPT [3367:880373] :OUTPUT ACCEPT [21464:1197423] COMMIT # Completed on Mon Jun 23 19:21:32 2008 And as I said, I tried with -o eth0 directly as well, but this doesn't=20 work better. >> I had a look at the big Linux Network Packet Flow picture that=20 >> describes how the packets are going through both ebtables and iptabl= es=20 >> rules, but I don't see anything that could be a problem. >=20 > As long as you don't have your kernel configured so that IPTables see= s=20 > bridged traffic, things should be fine. >=20 Actually this might be the case. I'm running a standard debian etch=20 kernel for the moment. I can consider building my own kernel, if=20 necessary. What is the kernel option I shouldn't enable ? >> for the masquerading, as I said, it's very simple : >> >> iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE >=20 > Again, why are you using "-o xenbr0" rather than "-o br2"? >=20 s/xenbr0/br2/ sorry :-) >> And I tried with eth0 instead of xenbr0, and I tried with SNAT,=20 >> specifying manually the IP address 172.16.33.200, but nothing worked= =2E >=20 > *nod* I think you are applying this to the wrong interface. >=20 No, I was just confused sorry, I think this is the good interface actua= lly. >> Regarding the routing, The HostC has nothing special : One default=20 >> route for each interface that has an IP address, so : >> 10.168.254.0 goes through br1 >> 172.16.33.0 goes through xenbr0 >> >> On HostA, I have this : >> 10.168.254.0 goes through eth0 >> 0.0.0.0 goes through gw 10.168.254.250 >> >> On HostB, I have : >> 10.168.254.0 goes through br0 >> 0.0.0.0 goes through gw 10.168.254.250 >> >> And on HostD, I just have : >> 172.16.33.0 goes through eth0 >> >> So I need masquerading so that HostD can reply to HostA without havi= ng=20 >> to setup a route on HostD to tell him how to do it. >=20 > *nod* >=20 >> Yes, I'm aware this is quite complex, and I understand that it might= =20 >> be difficult to help, especially because I'm using a PEP software=20 >> which might be quite difficult to setup if someone wants to reproduc= e=20 >> the problem. >> But still, as I said, the PEP stuff can be replaced by bridging the=20 >> two interfaces in the DomU together, it does the same, and I am able= =20 >> to reproduce the problem with such a setup as well. >=20 > *nod* >=20 >> I won't ;-) >=20 > Good! The more difficult the problem, the more rewarding it is when = you=20 > solve the problem. :) >=20 Yes, I hope it will work at some point. I will have a look to what you pointed regarding the option in the=20 kernel to have bridged packets not going through IPtables. Thanks :-) --=20 =46rancois Goudal Satcom1