All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Taylor, Grant" <gtaylor@riverviewtech.net>
To: netfilter@lists.netfilter.org
Subject: Re: Combined Internal/External DNAT question
Date: Sun, 15 May 2005 18:56:06 -0500	[thread overview]
Message-ID: <4287E196.5060403@riverviewtech.net> (raw)
In-Reply-To: <428591F3.8090400@griffous.net>

> iptables -t nat -A PREROUTING -d 10.0.0.1 -i eth1 -p tcp --dport
> <tcpservice> -j DNAT --to <relevant.internal.server>:<tcpservice>
> And this works nicely.

*nod* As I would expect it to do so.  :)

> However I have the classic situation of internal clients using the DNS
> entries for these servers which points them to my external IP. The
> firewall forwards the traffic out the dsl interface to the internet as
> it has no knowledge of my public IP. It doesn't work, the DSL router
> can't NAT to and from the LAN interface.

*nod*  You need to do some different D/SNATing on your firewall not the DSL modem / router.

> The following documentation is close to what I want, but doesn't quite work.
> http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html
> 
> The reason it doesn't work is that my firewall doesn't actually have the
> external IP.

This is not a problem.  You just have to tweak the rules slightly.

> What I need is rule along the lines of:
> iptables -t nat -I PREROUTING -d <publicIP> -s <internal-lan> -j DNAT
> --to 10.0.0.1.

You are very close but off by a destination IP.  See below.

> I would then have traffic from the internal lan, going the same
> destination IP that my public natting rules are already built for. Which
> should then redirect internal clients to my internal servers using these
> same natting rules.

This will not work as you have noticed for the reason you noticed below.

> It appears however that once iptables had done it's initial DNAT of a
> session as per the rule above, it doesn't reevalute the PREROUTING chain.
> 
> Which means that clients try to connect to the firewall itself rather
> then being DNATed again.

This is what I would expect to happen.

> HELP, I need some kind of a double DNAT?

No, you don't really want double DNAT.  What you really need to do (IMHO) is something you have alluded to that you do not want to do below.  You really need to use rules like this:

iptables -t nat -I PREROUTING -i <internal-lan-interface> -d <publicIP> -s <internal-lan> -j DNAT --to-destination <relevant.internal.server>:<tcpservice>

This will as you can probably guess cause your internal LAN traffic to that is outbound and destined to your public IP that your firewall knows nothing about to be DNATed to your real internal server.  However you will need to run an SNAT rule to prevent your internal server from responding directly to your internal LAN clients and thus causing a three way communications triangle where your client communicates (1st IP) to what it thinks is the server (2nd IP) which will redirect to the ultimate server (3rd IP) which will communicate directly back to your internal client thus confusing your internal client.

iptables -t nat -A POSTROUTING -d <relevant.internal.server> -j SNAT --to-source <internal interface of your firewall>

> I know there are solutions to this problem like dual dns, but getting
> this would be MUCH quicker to setup/manage/scale, and I wouldn't have to
> play DNS games.

I cant' say as I blame you for not wanting to maintain multiple (master) DNS spaces as this will open up another can of worms.

> I could also create a whole second set of rules DNATing internal traffic
> destined for my public IP, to go to the correct server, but then I'd
> have 2 chains of traffic to maintain. Is there no way I can do this all
> with one set of rules, on the one firewall?

Sorry, not that I'm aware of.  The only thing that comes to mind using one chain would be to do some funky routing tricks where the traffic would actually leave your firewall and then come back in the PREROUTING chain.  This in and of it's self is not very desirable and is cumbersome to maintain too.



Grant. . . .


  reply	other threads:[~2005-05-15 23:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-14  5:51 Combined Internal/External DNAT question Jonathan Wheeler
2005-05-15 23:56 ` Taylor, Grant [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-05-15 16:35 Gary W. Smith
2005-05-15 16:54 Gary W. Smith
     [not found] <42889941.5060507@griffous.net>
2005-05-16 18:35 ` Taylor, Grant
2005-05-16 19:27   ` R. DuFresne
2005-05-16 19:50     ` R. DuFresne
2005-05-16 21:06       ` Taylor, Grant
2005-05-19 10:53 Jonathan Wheeler

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=4287E196.5060403@riverviewtech.net \
    --to=gtaylor@riverviewtech.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.