From: Matin Tamizi <mtamizi@gmail.com>
To: jsimmons@goblin.punk.net
Cc: netfilter@lists.netfilter.org
Subject: Re: Routing and DNAT redux
Date: Thu, 9 Jun 2005 12:22:45 -0400 [thread overview]
Message-ID: <f68a41605060909226f26a9ba@mail.gmail.com> (raw)
In-Reply-To: <200506081754.50537.jsimmons@goblin.punk.net>
Why not use netfilter's SNAT and static routes via the route command?
You can use route to define the outgoing path for specific traffic:
For example:
route add -net 192.168.0.0 netmask 255.255.0.0 dev eth1
-Matin
On 6/8/05, Jeff Simmons <jsimmons@goblin.punk.net> wrote:
> OK, a little more specific.
>
> I have an iptables firewall with a server behind it. The server has a
> non-routable address (192.168) so the firewall's IP address:port is DNAT'd
> to the server's address:port.
>
> Incoming packets to the server first encounter the firewall's external
> interface (EXT_IF), where the prerouting DNAT rule rewrites the IP layer
> destination address (EXT_ADDR) to the server's address (SERV_ADDR). The
> packet is then passed on to the routing function, which determines that the
> packet needs forwarding via the internal interface (INT_IF). The packet is
> then passed through any appropriate iptables forwarding chains, then to the
> post-routing function of iptables (which in this case does nothing), and
> finally out INT_IF to destination SERV_ADDR.
>
> There's a nice diagram of this at:
>
> http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH03.web.html
>
> down in section 3.3.2.
>
> Now, to the reply from the server. When the packet leaves the server, its IP
> layer will show source SERV_ADDR destination REMOTE_ADDR. But when the packet
> arrives at the remote, it will show source EXT_ADDR destination REMOTE_ADDR.
> It gets rewritten somewhere.
>
> My understanding is the rewriting is done by the state engine, which basically
> maintains a rule that any outbound packet SERV_ADDR:port -> REMOTE_ADDR:port
> gets changed to EXT_ADDR:port -> REMOTE_ADDR:port. But where in the chain
> does this happen?
>
> Scenario one: it happens on INT_IF prerouting. If this is the case, then I can
> use source routing with iproute2.
>
> Scenario two: it happens on EXT_IF postrouting. Then iproute2 can't do the
> kind of source routing I need to do, and I'll have to find another solution.
>
> (Note that with standard destination routing, it doesn't matter where the
> packet gets rewritten. But with source routing it matters greatly.)
>
> The reality is, the box I'm working on has 4 T1s coming in, a DMZ with
> routable IP addresses, and two LANS with non-routable addresses where both
> contain servers that need to be contacted by the outside world via DNAT. It's
> a big, messy, ugly project, but I need to know if I can use iproute2 to be
> sure that return packets from all the servers go out the T1 they came in on.
>
> Any help, pointers, or FMs that I can RTFM would be GREATLY appreciated.
>
> --
> Jeff Simmons jsimmons@goblin.punk.net
> Simmons Consulting - Network Engineering, Administration, Security
>
> "You guys, I don't hear any noise. Are you sure you're doing it right?"
> -- My Life With The Thrill Kill Kult
>
>
next prev parent reply other threads:[~2005-06-09 16:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-09 0:54 Routing and DNAT redux Jeff Simmons
2005-06-09 16:22 ` Matin Tamizi [this message]
2005-06-09 17:00 ` Jeff Simmons
2005-06-10 17:55 ` Jason Opperisano
2005-06-10 18:05 ` Jeff Simmons
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=f68a41605060909226f26a9ba@mail.gmail.com \
--to=mtamizi@gmail.com \
--cc=jsimmons@goblin.punk.net \
--cc=netfilter@lists.netfilter.org \
/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.