All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ludovico Cavedon <cavedon@cs.ucsb.edu>
To: netfilter@vger.kernel.org
Cc: "Gáspár Lajos" <swifty@freemail.hu>
Subject: Re: invoking nat POSTROUTING *after* bridging decision
Date: Wed, 26 Jan 2011 14:07:25 -0800	[thread overview]
Message-ID: <4D409B1D.3070303@cs.ucsb.edu> (raw)
In-Reply-To: <4D407D65.9090902@freemail.hu>

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

      reply	other threads:[~2011-01-26 22:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-26 19:11 invoking nat POSTROUTING *after* bridging decision Ludovico Cavedon
2011-01-26 20:00 ` Gáspár Lajos
2011-01-26 22:07   ` Ludovico Cavedon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D409B1D.3070303@cs.ucsb.edu \
    --to=cavedon@cs.ucsb.edu \
    --cc=netfilter@vger.kernel.org \
    --cc=swifty@freemail.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.