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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox