* NAT issue on a machine with both routing and bridging.
@ 2008-06-23 14:22 Francois Goudal
2008-06-23 15:02 ` Grant Taylor
0 siblings, 1 reply; 8+ messages in thread
From: Francois Goudal @ 2008-06-23 14:22 UTC (permalink / raw)
To: netfilter
Hi,
I need to make a quite special setup today and I'm running in trouble at
some point :
I'm running a software that does TCP PEP (Performance Enhancement Proxy)
on a machine with 2 NICs. Basically, this machine can be considered as a
bridge (except that all the TCP traffic is converted to another
protocol, but all the rest like UDP or ICMP is simply going through
without being altered)
My setup also requires a NAT gateway that does masquerading.
This works fine with 2 separate boxes, one doing the PEP, and the other
doing the NAT gateway, and one crossover cable between them.
But now I have a challenge : all this should fit in one single box.
So I decided to use virtual machines, like Xen (I tried UML as well, so
my problem is not related to Xen specifically).
Here is the basic test setup I have :
................ ................
. HOST A . . HOST D .
. 10.168.254.1 . . 172.16.33.10 .
................ ................
| |
| |
| |
| eth1 eth0 |
.....................................................................
. |0.0.0.0 0.0.0.0 | .
. |__________________________________ ________________| .
. | | .
............................ |_ br0 | .
. eth0 . vif1.0 | 0.0.0.0 | .
. XEN VM _________._________| | .
. HOST B | 0.0.0.0 . 0.0.0.0 | .
. | . |_ br2 .
. br0 _| . | 172.16.33.200 .
. 10.168.254.51 | eth1 . vif1.1 | ^ .
. |_________._________ | .
. 0.0.0.0 . 0.0.0.0 | | Routing .
............................ |_ br1 | + DNAT .
. | 10.168.254.250 <--' .
. | .
. HOST C .
.....................................................................
Hosts A and D are here to test the stuff in host C+B.
Host C is a Xen Host machine that contains one Xen VM for the PEP stuff
and which is responsible for the masquerading of packets.
Host B is a Virtual machine running on Host C which runs the PEP software.
As you can see, the 2 NICs of the Host C are running without an IP
address but they are up and they are part of bridge interfaces.
eth1 is bridged together with vif1.0 (which corresponds to eth0 in the
HOST B) so that the eth1 of Host C can be considered as the eth0 of
HostB, so basically, all the traffic on eth1 of the Host C is going
to/coming from the Host B (the VM).
Since the Host B can be considered as a bridge, or just simply, a wire,
all this traffic gets out on eth1 of Host B, so back in the Host C as
vif1.1, which is part of a bridge which has an IP address : 10.168.254.250
This works fine, Host A can ping 10.168.254.250 (Host C) and we can see
the traffic going through Host B with tcpdump.
So it's like if there was no PEP stuff and eth1 had the IP address
10.168.254.250.
Now as you can see, on eth0 of Host C, we have a bridge with the IP
address 172.16.33.200. Host D can ping this IP address.
So we have both sides able to ping the gateway.
But now, I want Host A to be able to reach Host D through hosts C+B.
Regarding the routes : Host A has 10.168.254.250 (Host C) as a default
route, so when Host A wants to reach Host D, it sends the packets to
Host C+B.
Then, I tried to setup a route on Host D so that traffic to the subnet
10.168.254.0 goes through 172.16.33.200 and this works, Host A can
successfuly ping Host D.
But now, I want to get rid of the need of a special route on host D, so
I want to setup DNAT/Masquerade on the Host C.
Therefore, I have done this :
iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE
But when I ping D on A, and I look at what D receives, I can see the
real IP address of A, instead of the IP address of C (172.16.33.200)
I tried to do this as well :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
But this doesn't solve my problem.
Now, as a final test, I tried to ping host D from host B (the VM) and in
this case, I get masqueraded packets, with this rule :
iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE
So I suspect that on Host C, the packets that comes in the eth1 NIC are
not just forwarded to the VM by the bridge, but detected somehow by the
network stack and forwarded to eth0 (by some layer2 code ?) without
being masqueraded, then.
I have been working on trying to solve this during 2 days now but still
I can't find a solution.
Can anyone have a quick look and hopefully provide me an explaination
and maybe some help to find a solution ?
Best regards,
--
Francois Goudal
Satcom1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 14:22 NAT issue on a machine with both routing and bridging Francois Goudal
@ 2008-06-23 15:02 ` Grant Taylor
2008-06-23 15:25 ` Francois Goudal
0 siblings, 1 reply; 8+ messages in thread
From: Grant Taylor @ 2008-06-23 15:02 UTC (permalink / raw)
To: Mail List - Netfilter
On 06/23/08 09:22, Francois Goudal wrote:
> So I decided to use virtual machines, like Xen (I tried UML as well, so
> my problem is not related to Xen specifically).
This is starting to sound like a project that I would work on.
> ................ ................
> . HOST A . . HOST D .
> . 10.168.254.1 . . 172.16.33.10 .
> ................ ................
> | |
> | |
> | |
> | eth1 eth0 |
> .....................................................................
> . |0.0.0.0 0.0.0.0 | .
> . |__________________________________ ________________| .
> . | | .
> ............................ |_ br0 | .
> . eth0 . vif1.0 | 0.0.0.0 | .
> . XEN VM _________._________| | .
> . HOST B | 0.0.0.0 . 0.0.0.0 | .
> . | . |_ br2 .
> . br0 _| . | 172.16.33.200 .
> . 10.168.254.51 | eth1 . vif1.1 | ^ .
> . |_________._________ | .
> . 0.0.0.0 . 0.0.0.0 | | Routing .
> ............................ |_ br1 | + DNAT .
> . | 10.168.254.250 <--' .
> . | .
> . HOST C .
> .....................................................................
(Nice ASCII art)
> Host C is a Xen Host machine that contains one Xen VM for the PEP stuff
> and which is responsible for the masquerading of packets.
So Host C is Dom 0 and Host B is a Dom U, correct.
<snip>
> But now, I want to get rid of the need of a special route on host D, so
> I want to setup DNAT/Masquerade on the Host C.
*nod*
<snip>
> So I suspect that on Host C, the packets that comes in the eth1 NIC are
> not just forwarded to the VM by the bridge, but detected somehow by the
> network stack and forwarded to eth0 (by some layer2 code ?) without
> being masqueraded, then.
Can we see the output of brctl on Host C (domain 0)?
> I have been working on trying to solve this during 2 days now but still
> I can't find a solution.
Is there a reason that you are not masquerading packets that leave br2
in Host C?
> Can anyone have a quick look and hopefully provide me an explaination
> and maybe some help to find a solution ?
I need to see how things are bridged in Host C to be sure. I suspect
that either something is amiss in your bridging or where / how you were
doing your masquerading.
I will say that what you are wanting to do is sound and does work. I
have deployed multiple systems running complex networks in vms, be it
UML (multiple incarnations) and VMWare (any incarnation needing a
Windows vm). Presently I have multiple systems deployed that have one
host with up to 8 guest vms. These types of systems sound overly
complex. but the networking is usually the least complex part of them.
Don't give up.
Grant. . . .
Grant. . . .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 15:02 ` Grant Taylor
@ 2008-06-23 15:25 ` Francois Goudal
2008-06-23 15:48 ` Grant Taylor
0 siblings, 1 reply; 8+ messages in thread
From: Francois Goudal @ 2008-06-23 15:25 UTC (permalink / raw)
To: Grant Taylor; +Cc: Mail List - Netfilter
Grant Taylor a écrit :
> On 06/23/08 09:22, Francois Goudal wrote:
>> So I decided to use virtual machines, like Xen (I tried UML as well,
>> so my problem is not related to Xen specifically).
>
> This is starting to sound like a project that I would work on.
>
Thanks !
>> ................ ................
>> . HOST A . . HOST D .
>> . 10.168.254.1 . . 172.16.33.10 .
>> ................ ................
>> | |
>> | |
>> | |
>> | eth1 eth0 |
>> .....................................................................
>> . |0.0.0.0 0.0.0.0 | .
>> . |__________________________________ ________________| .
>> . | | .
>> ............................ |_ br0 | .
>> . eth0 . vif1.0 | 0.0.0.0 | .
>> . XEN VM _________._________| | .
>> . HOST B | 0.0.0.0 . 0.0.0.0 | .
>> . | . |_ br2 .
>> . br0 _| . | 172.16.33.200 .
>> . 10.168.254.51 | eth1 . vif1.1 | ^ .
>> . |_________._________ | .
>> . 0.0.0.0 . 0.0.0.0 | | Routing .
>> ............................ |_ br1 | + DNAT .
>> . | 10.168.254.250 <--' .
>> . | .
>> . HOST C .
>> .....................................................................
>
> (Nice ASCII art)
>
:-)
>> Host C is a Xen Host machine that contains one Xen VM for the PEP
>> stuff and which is responsible for the masquerading of packets.
>
> So Host C is Dom 0 and Host B is a Dom U, correct.
>
Yes, Host C is the Dom0 and Host B is a DomU here.
> <snip>
>
>> But now, I want to get rid of the need of a special route on host D,
>> so I want to setup DNAT/Masquerade on the Host C.
>
> *nod*
>
> <snip>
>
>> So I suspect that on Host C, the packets that comes in the eth1 NIC
>> are not just forwarded to the VM by the bridge, but detected somehow
>> by the network stack and forwarded to eth0 (by some layer2 code ?)
>> without being masqueraded, then.
>
> Can we see the output of brctl on Host C (domain 0)?
>
bridge name bridge id STP enabled interfaces
br1 8000.c6eabf59b7a0 no vif1.1
br0 8000.00304883f91f no eth1
vif1.0
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 have been working on trying to solve this during 2 days now but
>> still I can't find a solution.
>
> Is there a reason that you are not masquerading packets that leave br2
> in Host C?
>
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 :-/
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.
>> Can anyone have a quick look and hopefully provide me an explaination
>> and maybe some help to find a solution ?
>
> I need to see how things are bridged in Host C to be sure. I suspect
> that either something is amiss in your bridging or where / how you were
> doing your masquerading.
>
for the masquerading, as I said, it's very simple :
iptables -t nat -A POSTROUTING -o xenbr0 -j MASQUERADE
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.
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.
> I will say that what you are wanting to do is sound and does work. I
> have deployed multiple systems running complex networks in vms, be it
> UML (multiple incarnations) and VMWare (any incarnation needing a
> Windows vm). Presently I have multiple systems deployed that have one
> host with up to 8 guest vms. These types of systems sound overly
> complex. but the networking is usually the least complex part of them.
>
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.
> Don't give up.
I won't ;-)
Thank's for your time.
Best regards.
--
Francois Goudal
Satcom1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 15:25 ` Francois Goudal
@ 2008-06-23 15:48 ` Grant Taylor
2008-06-23 16:00 ` Francois Goudal
0 siblings, 1 reply; 8+ messages in thread
From: Grant Taylor @ 2008-06-23 15:48 UTC (permalink / raw)
To: Mail List - Netfilter
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.
> 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 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.
> 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"?
> 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.
> 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. :)
> Thank's for your time.
*nod*
> Best regards.
Likewise.
Grant. . . .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 15:48 ` Grant Taylor
@ 2008-06-23 16:00 ` Francois Goudal
2008-06-23 16:42 ` Grant Taylor
0 siblings, 1 reply; 8+ messages in thread
From: Francois Goudal @ 2008-06-23 16:00 UTC (permalink / raw)
To: Grant Taylor; +Cc: Mail List - Netfilter
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 16:00 ` Francois Goudal
@ 2008-06-23 16:42 ` Grant Taylor
2008-06-24 8:41 ` Francois Goudal
0 siblings, 1 reply; 8+ messages in thread
From: Grant Taylor @ 2008-06-23 16:42 UTC (permalink / raw)
To: Mail List - Netfilter
On 06/23/08 11:00, Francois Goudal wrote:
> 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.
*nod*
> 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
Ok, there is nothing that is preventing things from working.
> And as I said, I tried with -o eth0 directly as well, but this doesn't
> work better.
Hum.
> 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 ?
The option that I'm referring to is "CONFIG_BRIDGE_NETFILTER". This
option sets whether or not IPTables (layer 3 and above) sees bridged
(layer 2) traffic or not.
> s/xenbr0/br2/ sorry :-)
*nod*
> No, I was just confused sorry, I think this is the good interface actually.
Agreed.
> 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.
I don't see any thing in what you have presented that will make this be
a problem with the configuration that you have described.
> Thanks :-)
*nod*
I don't see any thing that (in theory) should not work. The only thing
that comes to mind is to temporarily remove Host B (DomU) from the mix
and bridge br1 directly to eth1 and try your MASQUERADing between two
bridge interfaces.
The only other thing that comes to mind is that you may be trying to nat
existing connections, which can not be done because only the first
packet in the connection passes through the NAT table. But I don't
think this is likely.
Grant. . . .
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-23 16:42 ` Grant Taylor
@ 2008-06-24 8:41 ` Francois Goudal
2008-06-24 14:29 ` Grant Taylor
0 siblings, 1 reply; 8+ messages in thread
From: Francois Goudal @ 2008-06-24 8:41 UTC (permalink / raw)
To: Grant Taylor, Mail List - Netfilter
Grant Taylor a écrit :
> On 06/23/08 11:00, Francois Goudal wrote:
>> 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 ?
>
> The option that I'm referring to is "CONFIG_BRIDGE_NETFILTER". This
> option sets whether or not IPTables (layer 3 and above) sees bridged
> (layer 2) traffic or not.
>
Ok, I checked this, and it appears that in the standard Debian kernel I
use, this is enabled. But still, my iptables are almost empty, there's
just one single rule, for the masqueading, and I don't think this can
have an impact on bridged packets, can it ?
>
> I don't see any thing that (in theory) should not work. The only thing
> that comes to mind is to temporarily remove Host B (DomU) from the mix
> and bridge br1 directly to eth1 and try your MASQUERADing between two
> bridge interfaces.
>
Okay, I did a quick test, by just removing eth1 from br0 and putting it
in br1, but keeping the DomU, still.
So now, it looks like this :
................ ................
. HOST A . . HOST D .
. 10.168.254.1 . . 172.16.33.10 .
................ ................
| |
| |
| |
| eth1 eth0 |
.....................................................................
. |0.0.0.0 0.0.0.0 | .
. |_____________________________________________ ________________| .
. || .
............................ _ br0 || .
. eth0 . vif1.0 | 0.0.0.0 || .
. XEN VM _________._________| || .
. HOST B | 0.0.0.0 . 0.0.0.0 _____|| .
. | . | |_ br2 .
. br0 _| . | | 172.16.33.200 .
. 10.168.254.51 | eth1 . vif1.1 | | ^ .
. |_________._________ ____| | .
. 0.0.0.0 . 0.0.0.0 | | Routing .
............................ |_ br1 | + DNAT .
. | 10.168.254.250 <--' .
. | .
. HOST C .
.....................................................................
The VM is still here, but all the traffic from/to eth1 is not going
through it, but reaches directly br1.
And actually, in this configuration, the packets from Host A to Host D
are correctly masqueraded by Host C. Packets from Host B to Host D are
still correctly masqueraded as well.
If I remove the VM completely, it works, also, but the previous test
shows that the problem does not come from the presence of the VM, but
the way all this is "connected".
> The only other thing that comes to mind is that you may be trying to nat
> existing connections, which can not be done because only the first
> packet in the connection passes through the NAT table. But I don't
> think this is likely.
>
I'm doing my tests with ICMP Echo messages, for the moment, this is not
something that has connection states, it must work, the tests with TCP
traffic comes later, once this basic stuff will work.
Regards,
--
Francois Goudal
Satcom1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: NAT issue on a machine with both routing and bridging.
2008-06-24 8:41 ` Francois Goudal
@ 2008-06-24 14:29 ` Grant Taylor
0 siblings, 0 replies; 8+ messages in thread
From: Grant Taylor @ 2008-06-24 14:29 UTC (permalink / raw)
To: Mail List - Netfilter
On 06/24/08 03:41, Francois Goudal wrote:
> Ok, I checked this, and it appears that in the standard Debian kernel I
> use, this is enabled. But still, my iptables are almost empty, there's
> just one single rule, for the masqueading, and I don't think this can
> have an impact on bridged packets, can it ?
This option allows IPTables to be able to intercept packets but your
IPTables configuration is not doing so, thus I don't think this is
having any impact for you.
> Okay, I did a quick test, by just removing eth1 from br0 and putting it
> in br1, but keeping the DomU, still.
> So now, it looks like this :
<snip>
> The VM is still here, but all the traffic from/to eth1 is not going
> through it, but reaches directly br1.
*nod*
> And actually, in this configuration, the packets from Host A to Host D
> are correctly masqueraded by Host C. Packets from Host B to Host D are
> still correctly masqueraded as well.
Ok...
> If I remove the VM completely, it works, also, but the previous test
> shows that the problem does not come from the presence of the VM, but
> the way all this is "connected".
So, just to make sure we are on the same page, your belief is that by
bypassing Host B things are indeed working, and as such the problem has
something (as of yet unknown) to do with Host B. Correct?
If so, I agree. However, based on the fact that Host A could get to
Host C with out a problem while Host B was in the mix, I don't see any
thing obvious about Host B that would be interfering.
> I'm doing my tests with ICMP Echo messages, for the moment, this is not
> something that has connection states, it must work, the tests with TCP
> traffic comes later, once this basic stuff will work.
For what you are testing at the moment, I'd say it's "ok" to be using
ICMP rather than TCP. Just be aware that some tests do behave
differently depending on what protocol you are testing. Load balancing
is notorious that you need to test the protocol you are going to use.
Just keep that in mind. It may be worth a simple ""telnet to a clear
text port (25, 80, 110, ...).
Grant. . . .
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-06-24 14:29 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-23 14:22 NAT issue on a machine with both routing and bridging Francois Goudal
2008-06-23 15:02 ` Grant Taylor
2008-06-23 15:25 ` Francois Goudal
2008-06-23 15:48 ` Grant Taylor
2008-06-23 16:00 ` Francois Goudal
2008-06-23 16:42 ` Grant Taylor
2008-06-24 8:41 ` Francois Goudal
2008-06-24 14:29 ` Grant Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox