Re: NAT issue on a machine with both routing and bridging.

[Francois Goudal <fg@satcom1.com>]

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