invoking nat POSTROUTING *after* bridging decision

invoking nat POSTROUTING *after* bridging decision

[Ludovico Cavedon]

Hi,

I have a machine which has two interfaces bridged together (eth0 and
eth1, on br0), plus a third interface eth2 on a separate network.

I would like to masquerade traffic from the eth2 network only if it sent
over eth0, and not if it is sent over eth1.

My problem is that the -t nat POSTROUTING rule is invoked after the
routing decision, before the packet enters the bridge. (i.e. with output
interface br0).

Is there any way to postpone the call to POSTROUTING after the bridging
decision has been been, or have the POSTROUTING chain called twice?

Thank you in advance,
Cheers,
Ludovico

PS:
For sake of completeness, I was able to get the NAT to work, by using a
POSTRUTING rules based on IP address, rather than output interfaces, as
I know which hosts are connected to each interface (eth0 or eth1).
However, if I run tcpdump in br0, I see outgoing packets with source IP
address masqueraded, but incoming packets have already been
un-masqueraded, making it annoyingly asymmetric...

Re: invoking nat POSTROUTING *after* bridging decision

[Gáspár Lajos]

Hi,

> Is there any way to postpone the call to POSTROUTING after the bridging
> decision has been been, or have the POSTROUTING chain called twice?
I don't think it is possible...
But could you please explain us why do you want such NATing?
Maybe we can help you out with an other setup...

Swifty

Re: invoking nat POSTROUTING *after* bridging decision

[Ludovico Cavedon]

On 01/26/2011 12:00 PM, Gáspár Lajos wrote:
>> Is there any way to postpone the call to POSTROUTING after the bridging
>> decision has been been, or have the POSTROUTING chain called twice?
> I don't think it is possible...
> But could you please explain us why do you want such NATing?
> Maybe we can help you out with an other setup...

Sure, thank you for asking, here it is:

Host: myfw
br0: 10.10.10.2/24
	eth0: connected to 10.10.10.1, acting as gateway to the Internet
	eth1: connected to the rest of the 10.10.10.0/24 network

hosts in the 10.10.10.0/24 network are configured with 10.10.10.1 as
default gateway. I am using the host myfw to act as transparent firewall
for the 10.10.10.0/24 network (which in reality is a publicly routable
network).

I cannot change the configuration of the hosts in the 10.10.10.0/24 network.

So far so good.

Then, always on the myfw machine, I have:
-eth2: 192.168.1.1, connected to the 192.168.1.0/24 network

myfw is acting as gateway for the 192.168.1.0/24 network.

More in detail, myfw should:
-route traffic between 192.168.1.0/24 and 10.10.10.0/24 (eth1)
-masquerade traffic from 192.168.1.0./24 towards the outside via
10.10.10.1 (eth0)

I managed to get this configuration working with the following iptables
and ebtables rules:

# intercept packets for the private network
ebtables -t nat -A PREROUTING -i 10.10.10.0/24 -p ipv4 --ip-destination
192.168.1.0./24 -j redirect --redirect-target ACCEPT

# SNAT packets directed to the outside world
iptables -t nat -A POSTROUTING -s 192.168.1.0./24 -o br0 ! -d
10.10.10.0/24 -j SNAT --to-source 10.10.10.2


As I said, this is working, but when I run tcpdump on br0, for
connections originating from the private network, I see outgoing packets
with source IP address masqueraded (10.10.10.2), but incoming packets
already un-masqueraded (i.e. the actual address in the private network).
This complicates running monitoring tools like ntop, other than being
oddly asymmetric.

I hope I included all relevant information.
Thanks for any suggestion about this!

Cheers,
Ludovico