Grant Taylor a écrit :
On 06/23/08 10:25, Francois Goudal wrote:
Yes, Host C is the Dom0 and Host B is a DomU here.
*nod*
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
don't think the problem comes from the bridge configuration, but you
will probably tell me if you can see sth wrong here :-)
I don't see any thing obviously wrong. At least the output of brctl
seems to line up with your ASCII art.
Ok, at least this is good :-)
I don't understand your question. I want them to be masqueraded, but
the fact is that I can't get them masqueraded when they come from a
machine connected to eth1 on the Dom0. But they are masqueraded when
they come from the DomU. But I don't see any reason for that
difference. On the Dom0, the eth1 interface is linked with a bridge to
one interface of the DomU but no IP addresses are set (on eth1 itself,
on the bridge interface it belongs to, and on the Xen backend
interface which is in the bridge) so the traffic has to go through the
DomU, so now, why is it working with the DomU itself but not with the
hosts connected on eth1, I have no idea :-/
Why are you not masquerading the packets that leave br2 in Host C (Dom0)?
hostC# iptables -t nat -A POSTROUTING -o br2 -j MASQUERADE
Not having run Xen my self, I'm not sure how the br# lines up with
xenbr# so I can't say for sure.
What does iptables-save on Host C (Dom0) have to say?
I'm sorry, this is my mistake, you should replace xenbr0 by br2 in all
what I said, this is because I have done the setup again on another
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
work better.
I had a look at the big Linux Network Packet Flow picture that
describes how the packets are going through both ebtables and iptables
rules, but I don't see anything that could be a problem.
As long as you don't have your kernel configured so that IPTables sees
bridged traffic, things should be fine.
Actually this might be the case. I'm running a standard debian etch
kernel for the moment. I can consider building my own kernel, if
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
Again, why are you using "-o xenbr0" rather than "-o br2"?
s/xenbr0/br2/ sorry :-)
And I tried with eth0 instead of xenbr0, and I tried with SNAT,
specifying manually the IP address 172.16.33.200, but nothing worked.
*nod* I think you are applying this to the wrong interface.
No, I was just confused sorry, I think this is the good interface actually.
Regarding the routing, The HostC has nothing special : One default
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 having
to setup a route on HostD to tell him how to do it.
*nod*
Yes, I'm aware this is quite complex, and I understand that it might
be difficult to help, especially because I'm using a PEP software
which might be quite difficult to setup if someone wants to reproduce
the problem.
But still, as I said, the PEP stuff can be replaced by bridging the
two interfaces in the DomU together, it does the same, and I am able
to reproduce the problem with such a setup as well.
*nod*
I won't ;-)
Good! The more difficult the problem, the more rewarding it is when you
solve the problem. :)
Yes, I hope it will work at some point.
I will have a look to what you pointed regarding the option in the
kernel to have bridged packets not going through IPtables.
Thanks :-)
--
Francois Goudal
Satcom1
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
