Combined Internal/External DNAT question

Combined Internal/External DNAT question

[Jonathan Wheeler]

Hi Guys,

I have a number of internal servers sitting behind my iptables firewall
running various services (smtp/http/dns etc).
My public IP address sits on my DSL router's WAN interface, which nats
the specified ports for my public services to the firewall's interface &
IP which is attached to the router via crossover cable.

Iptables has about 15 entries all along the lines of

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.

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.

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.

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.
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.

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.

HELP, I need some kind of a double DNAT?

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 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?

Thanks,
Jonathan.

Re: Combined Internal/External DNAT question

[Taylor, Grant]

> 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. . . .

RE: Combined Internal/External DNAT question

[Gary W. Smith]

I've always received an answer which has never helped for this question
of this not being necessary.  Anyways, here is what we do that does work
which I'm sure you can change to suit your needs.

-A POSTROUTING -s 10.0.0.130 -o eth0 -j SNAT --to-source 30.40.50.130 
-A POSTROUTING -s 10.0.0.0/255.255.255.0 -d 10.0.0.130 -j SNAT
--to-source 30.40.50.130

eth0 is the external interface for some reason we loose the second line
internal machines cannot access other internal machines with the
external IP.  I've had mixed results dropping the eth0 on the first
line.  If I recall internal hosts pinging internal hosts on their
internal or external IP would always respond with their external IP
which also screwed things up.

It should be similar for you but with ports specified.

Hope that helps, 

Gary

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Jonathan Wheeler
> Sent: Friday, May 13, 2005 10:52 PM
> To: netfilter@lists.netfilter.org
> Subject: Combined Internal/External DNAT question
> 
> Hi Guys,
> 
> I have a number of internal servers sitting behind my iptables
firewall
> running various services (smtp/http/dns etc).
> My public IP address sits on my DSL router's WAN interface, which nats
> the specified ports for my public services to the firewall's interface
&
> IP which is attached to the router via crossover cable.
> 
> Iptables has about 15 entries all along the lines of
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 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.
> 
> 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.
> 
> HELP, I need some kind of a double DNAT?
> 
> 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 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?
> 
> Thanks,
> Jonathan.

RE: Combined Internal/External DNAT question

[Gary W. Smith]

On that same topic, we a /25 subnet into the DMZ.  We end up with
something like section below.  You will notice that we also have the
double POSTROUTING entries as well as the output section.  In out case
we had to create a patch for the NETMAP code but that doesn't apply to
you though.



#############################################################
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
#############################################################
# Prerouting Maps
#############################################################
[0:0] -A PREROUTING -d 33.44.55.128 -j RETURN
[0:0] -A PREROUTING -d 33.44.55.129 -j RETURN
[0:0] -A PREROUTING -d 33.44.55.128/26 -j NETMAP --to 10.0.0.128/26
[0:0] -A PREROUTING -d 33.44.55.192/27 -j NETMAP --to 10.0.0.192/27
[0:0] -A PREROUTING -d 33.44.55.224/28 -j NETMAP --to 10.0.0.224/28
[0:0] -A PREROUTING -d 33.44.55.248/30 -j NETMAP --to 10.0.0.248/30
#############################################################
# Postrouting Maps
#############################################################
[0:0] -A POSTROUTING -s 10.0.0.128 -j RETURN
[0:0] -A POSTROUTING -s 10.0.0.129 -j RETURN
[0:0] -A POSTROUTING -o eth0 -s 10.0.0.128/26 -j NETMAP --to
33.44.55.128/26
[0:0] -A POSTROUTING -o eth0 -s 10.0.0.192/27 -j NETMAP --to
33.44.55.192/27
[0:0] -A POSTROUTING -o eth0 -s 10.0.0.224/28 -j NETMAP --to
33.44.55.224/28
[0:0] -A POSTROUTING -o eth0 -s 10.0.0.248/30 -j NETMAP --to
33.44.55.248/30


# Without these, local lookups on the same network fail to
# find the server

[0:0] -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.128/26   -j NETMAP --to
33.44.55.128/26
[0:0] -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.192/27   -j NETMAP --to
33.44.55.192/27
[0:0] -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.224/28   -j NETMAP --to
33.44.55.224/28
[0:0] -A POSTROUTING -s 10.0.0.0/24 -d 10.0.0.248/30   -j NETMAP --to
33.44.55.248/30

[0:0] -A POSTROUTING -o eth0 -p ! esp -j SNAT --to-source 33.44.55.254

#############################################################
# Output Maps
# customized NETMAP to support OUTPUT
#############################################################
[0:0] -A OUTPUT -d 33.44.55.128 -j RETURN
[0:0] -A OUTPUT -d 33.44.55.129 -j RETURN
[0:0] -A OUTPUT -d 33.44.55.128/26 -j NETMAP --to 10.0.0.128/26
[0:0] -A OUTPUT -d 33.44.55.192/27 -j NETMAP --to 10.0.0.192/27
[0:0] -A OUTPUT -d 33.44.55.224/28 -j NETMAP --to 10.0.0.224/28
[0:0] -A OUTPUT -d 33.44.55.248/30 -j NETMAP --to 10.0.0.248/30

COMMIT


> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Gary W. Smith
> Sent: Sunday, May 15, 2005 9:36 AM
> To: Jonathan Wheeler; netfilter@lists.netfilter.org
> Subject: RE: Combined Internal/External DNAT question
> 
> -A POSTROUTING -s 10.0.0.130 -o eth0 -j SNAT --to-source 30.40.50.130
> -A POSTROUTING -s 10.0.0.0/255.255.255.0 -d 10.0.0.130 -j SNAT
> --to-source 30.40.50.130
> 
> 

Re: Combined Internal/External DNAT question

[Taylor, Grant]

> My problem still remains however Grant. I would have to create another DNAT rule to match each existing *real* public DNAT rule that currently exists to DNAT traffic from the Internet.  Do you have any further ideas for me? Given that a packet can have both the src and dst IP address rewritten in it's one trip through iptables, it seems to me that it should be possible for two rewrites to happen at once. My thinking it perhaps breaking the nat table into several chains?  Any other suggestions, you've been most helpful so far.


The only other thing that comes to mind would be to use iphash (IP)sets of destination IP addresses on your original DNAT rules.  This would cause your iptables rule to match based on the destination of your external IP of your firewall OR your external IP of your DSL modem (/router) and DNAT the traffic to the real server on your 2nd internal subnet.  Here is an example rule for what you would need:

iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT --to-destination <relevant.internal.server>:<tcpservice>

To support this rule you would need to do the following (likely before you issued the above rule):

ipset -N My_IP_Set iphash
ipset -A My_IP_Set 10.0.0.1
ipset -A My_IP_Set <Public IP>

As stated before this should cause your one iptables rule to match packets that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets to the <relevant.internal.server>:<tcpservice>.  I know that this is not the multiple passes through the iptables chains like you were asking for, but I think it will provide a solution comparable  to the result that you were after.  Rather than have a rule that will alter traffic such that it will be caught by another rule and then altered again why not have a rule that will catch either type of traffic.



Grant. . . .

Re: Combined Internal/External DNAT question

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 16 May 2005, Taylor, Grant wrote:

>> My problem still remains however Grant. I would have to create another 
>> DNAT rule to match each existing *real* public DNAT rule that currently 
>> exists to DNAT traffic from the Internet.  Do you have any further ideas 
>> for me? Given that a packet can have both the src and dst IP address 
>> rewritten in it's one trip through iptables, it seems to me that it should 
>> be possible for two rewrites to happen at once. My thinking it perhaps 
>> breaking the nat table into several chains?  Any other suggestions, you've 
>> been most helpful so far.
>
>
> The only other thing that comes to mind would be to use iphash (IP)sets of 
> destination IP addresses on your original DNAT rules.  This would cause your 
> iptables rule to match based on the destination of your external IP of your 
> firewall OR your external IP of your DSL modem (/router) and DNAT the traffic 
> to the real server on your 2nd internal subnet.  Here is an example rule for 
> what you would need:
>
> iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT 
> --to-destination <relevant.internal.server>:<tcpservice>
>
> To support this rule you would need to do the following (likely before you 
> issued the above rule):
>
> ipset -N My_IP_Set iphash
> ipset -A My_IP_Set 10.0.0.1
> ipset -A My_IP_Set <Public IP>
>
> As stated before this should cause your one iptables rule to match packets 
> that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets 
> to the <relevant.internal.server>:<tcpservice>.  I know that this is not the 
> multiple passes through the iptables chains like you were asking for, but I 
> think it will provide a solution comparable  to the result that you were 
> after.  Rather than have a rule that will alter traffic such that it will be 
> caught by another rule and then altered again why not have a rule that will 
> catch either type of traffic.
>

Actually, if this does not help the original poster, it may work in my 
issues in the thread on "okay I admit confusion here..."

I think my best solution is one to one nat of public addresses to internal 
private addresses.  Means I have to put some post/pre routing rules in 
place and I might beable to shorten that all up with IP hashes as you are 
suggesting here.  But, all in all I think that sure beats bridging 
interfaces and dealing with trying to firewall at layer2...


Thanks,


Ron DuFresne
- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCiPQzst+vzJSwZikRAtEWAKCy8I6X6s5EwnsIWNPw5Kmo/pyO5wCdHFe4
c4qm+DWsr0VvOtqZxHdGyFU=
=xH0c
-----END PGP SIGNATURE-----

Re: Combined Internal/External DNAT question

[R. DuFresne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


an interesting tidbit from the iptables man pages suggests that their is a 
built in facility for this one to one nat thingie I'm looking into here;

    NETMAP
        This  target allows you to statically map a whole network of 
addresses onto another network of addresses.
        It can only be used from rules in the nat table.

        --to address[/mask]
               Network address to map to.  The resulting address will be 
constructed in the  following  way:  All
               'one'  bits  in the mask are filled in from the new 
`address'.  All bits that are zero in the mask
               are filled in from the original address.


If I read this correctly, it appears to build the hash tables of addresses 
for one eh?

Thanks,

Ron DuFresne

On Mon, 16 May 2005, R. DuFresne wrote:

> --[PinePGP]--------------------------------------------------[begin]--
> On Mon, 16 May 2005, Taylor, Grant wrote:
>
>>> My problem still remains however Grant. I would have to create another
>>> DNAT rule to match each existing *real* public DNAT rule that currently
>>> exists to DNAT traffic from the Internet.  Do you have any further ideas
>>> for me? Given that a packet can have both the src and dst IP address
>>> rewritten in it's one trip through iptables, it seems to me that it 
>>> should
>>> be possible for two rewrites to happen at once. My thinking it perhaps
>>> breaking the nat table into several chains?  Any other suggestions, 
>>> you've
>>> been most helpful so far.
>> 
>> 
>> The only other thing that comes to mind would be to use iphash (IP)sets of
>> destination IP addresses on your original DNAT rules.  This would cause 
>> your
>> iptables rule to match based on the destination of your external IP of 
>> your
>> firewall OR your external IP of your DSL modem (/router) and DNAT the 
>> traffic
>> to the real server on your 2nd internal subnet.  Here is an example rule 
>> for
>> what you would need:
>> 
>> iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT
>> --to-destination <relevant.internal.server>:<tcpservice>
>> 
>> To support this rule you would need to do the following (likely before you
>> issued the above rule):
>> 
>> ipset -N My_IP_Set iphash
>> ipset -A My_IP_Set 10.0.0.1
>> ipset -A My_IP_Set <Public IP>
>> 
>> As stated before this should cause your one iptables rule to match packets
>> that are destined to any IP in the ip set "My_IP_Set" and DNAT said 
>> packets
>> to the <relevant.internal.server>:<tcpservice>.  I know that this is not 
>> the
>> multiple passes through the iptables chains like you were asking for, but 
>> I
>> think it will provide a solution comparable  to the result that you were
>> after.  Rather than have a rule that will alter traffic such that it will 
>> be
>> caught by another rule and then altered again why not have a rule that 
>> will
>> catch either type of traffic.
>> 
>
> Actually, if this does not help the original poster, it may work in my
> issues in the thread on "okay I admit confusion here..."
>
> I think my best solution is one to one nat of public addresses to internal
> private addresses.  Means I have to put some post/pre routing rules in
> place and I might beable to shorten that all up with IP hashes as you are
> suggesting here.  But, all in all I think that sure beats bridging
> interfaces and dealing with trying to firewall at layer2...
>
>
> Thanks,
>
>
> Ron DuFresne
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        admin & senior security consultant:  sysinfo.com
>                        http://sysinfo.com
> Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629
>
> ...We waste time looking for the perfect lover
> instead of creating the perfect love.
>
>                -Tom Robbins <Still Life With Woodpecker>
> --[PinePGP]-----------------------------------------------------------
> gpg: Signature made Mon 16 May 2005 03:27:47 PM EDT using DSA key ID 94B06629
> gpg: Good signature from "dufresne <dufresne@sysinfo.com>"
> --[PinePGP]----------------------------------------------------[end]--
>

- -- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         admin & senior security consultant:  sysinfo.com
                         http://sysinfo.com
Key fingerprint = 9401 4B13 B918 164C 647A  E838 B2DF AFCC 94B0 6629

...We waste time looking for the perfect lover
instead of creating the perfect love.

                 -Tom Robbins <Still Life With Woodpecker>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCiPmWst+vzJSwZikRAnNJAKDH9bP49JIBtFn1wK5Xbre/CHoNlgCffM0s
fQET0waj7L4hdtx/EbPmaZY=
=0jZG
-----END PGP SIGNATURE-----

Re: Combined Internal/External DNAT question

[Taylor, Grant]

> an interesting tidbit from the iptables man pages suggests that their is 
> a built in facility for this one to one nat thingie I'm looking into here;
> 
> NETMAP
>        This  target allows you to statically map a whole network of addresses onto another network of addresses.
>        It can only be used from rules in the nat table.
> 
>        --to address[/mask]
>               Network address to map to.  The resulting address will be constructed in the  following  way:  All
>               'one'  bits  in the mask are filled in from the new `address'.  All bits that are zero in the mask
>               are filled in from the original address.
> 
> If I read this correctly, it appears to build the hash tables of 
> addresses for one eh?

As I understand it the NETMAP target is used to do NATing on a large range ((sub)network) of IPs in on rule.  Thus you could directly translate 192.168.0.1 <-> 172.16.0.1, 192.168.0.2 <-> 172.16.0.2, 192.168.0.n <-> 172.16.0.n, etc.

As far as your situation are you really wanting each computer on your network to have a globally routable IP?  If not then you do not need / want to look at NETMAP.



Grant. . . .

Combined Internal/External DNAT question

[Jonathan Wheeler]

The only other thing that comes to mind would be to use iphash (IP)sets of destination IP addresses on your original DNAT rules.  This would cause your iptables rule to match based on the destination of your external IP of your firewall OR your external IP of your DSL modem (/router) and DNAT the traffic to the real server on your 2nd internal subnet.  Here is an example rule for what you would need:

iptables -t nat -A PREROUTING -m set --set My_IP_Set dst -j DNAT --to-destination <relevant.internal.server>:<tcpservice>

To support this rule you would need to do the following (likely before you issued the above rule):

ipset -N My_IP_Set iphash
ipset -A My_IP_Set 10.0.0.1
ipset -A My_IP_Set <Public IP>

As stated before this should cause your one iptables rule to match packets that are destined to any IP in the ip set "My_IP_Set" and DNAT said packets to the <relevant.internal.server>:<tcpservice>.  I know that this is not the multiple passes through the iptables chains like you were asking for, but I think it will provide a solution comparable  to the result that you were after.  Rather than have a rule that will alter traffic such that it will be caught by another rule and then altered again why not have a rule that will catch either type of traffic.

Grant. . . .



Thanks for the reply Grant, 

Sorry for not getting back to you earlier. You're quite right, this should work nicely but I'm not so keen on running the non-default modules at the moment.
For simply getting my machine working for the testing that I need to be doing, a simply iptables -t nat -A OUTPUT is able to fix the problem for me, though
of course any other clients still have the problem.

Once I have all the rest of the network running I'll come back to using the set module.

Thanks again,
Jonathan.