Need to solve a NAT problem, any takers.

Need to solve a NAT problem, any takers.

[Gary W. Smith]

Hello, 

I just setup a new firewall that works well but we ran into a loop with
NAT.  We have a single public IP address which we have to route a web
server, DNS and MTA server through.  These are all on different internal
IP's.  We use PREROUTING DNAT for the IP's coming in.  This works fine.

Internally our DNS server are split giving us internal IP's when queried
internally and external's when queried externally.  This works fine.
Our second DNS server internally slaves the primary.  Because we are
using this split functionality when it slaves the internal IP's it gets
the internal IP configuration.  Works great.  But in order to replicate
the external range it must do so by replicating from the external IP.
This fails at the IP's is NAT'd in by port only.  Years ago we solved
this by running a second POSTROUTING rule and an OUTPUT rule on the
firewall.  When I load these rules now 

Jan 11 18:11:41 hsfiw01 kernel: NAT: no longer support implicit source
local NAT
Jan 11 18:11:41 hsfiw01 kernel: NAT: packet src 10.40.0.13 -> dst
80.80.80.66

I understand that this is now expected functionality in the 2.6.11+
kernels.  We are running 2.6.16 (which we kind of stuck on right now).

Is there a way to run work around this problem to allow internal
machines to use the external NAT'd IP via specific port to access the
proper machine inside?

Here is something that I derived from an older config, but obviously the
POSTROUTING isn't working.

-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 80     -j DNAT
--to-destination 10.40.0.12:80
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 443    -j DNAT
--to-destination 10.40.0.12:443
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 25     -j DNAT
--to-destination 10.40.0.13:25
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 53     -j DNAT
--to-destination 10.40.0.13:53
-A PREROUTING -d 80.80.80.66 -p udp -m udp --dport 53     -j DNAT
--to-destination 10.40.0.13:53
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 20009  -j DNAT
--to-destination 10.40.0.9:22
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 20011  -j DNAT
--to-destination 10.40.0.11:22
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 20012  -j DNAT
--to-destination 10.40.0.12:22
-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 20013  -j DNAT
--to-destination 10.40.0.13:22

#-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 110    -j DNAT
--to-destination 10.40.0.13:110
#-A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 143    -j DNAT
--to-destination 10.40.0.13:143

-A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p tcp -m tcp --sport 53 -j
SNAT --to-source 80.80.80.66:53
-A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p udp -m udp --sport 53 -j
SNAT --to-source 80.80.80.66:53

-A POSTROUTING -o eth0 -j MASQUERADE

-A OUTPUT -d 80.80.80.66 -p tcp -m tcp --dport 53 -j DNAT
--to-destination 10.40.0.13:53
-A OUTPUT -d 80.80.80.66 -p udp -m udp --dport 53 -j DNAT
--to-destination 10.40.0.13:53

Any help would be greatly appreciated.

Gary Wayne Smith

Re: Need to solve a NAT problem, any takers.

[Pascal Hambourg]

Hello,

Gary W. Smith a écrit :
> 
> Internally our DNS server are split giving us internal IP's when queried
> internally and external's when queried externally.  This works fine.
> Our second DNS server internally slaves the primary.  Because we are
> using this split functionality when it slaves the internal IP's it gets
> the internal IP configuration.  Works great.  But in order to replicate
> the external range it must do so by replicating from the external IP.

Just being curious : why do you want to replicate the external view on 
the slave DNS server ? If I understand correctly, only the primary DNS 
server is reachable from the outside.

> This fails at the IP's is NAT'd in by port only.  Years ago we solved
> this by running a second POSTROUTING rule and an OUTPUT rule on the
> firewall.  When I load these rules now 
> 
> Jan 11 18:11:41 hsfiw01 kernel: NAT: no longer support implicit source
> local NAT
> Jan 11 18:11:41 hsfiw01 kernel: NAT: packet src 10.40.0.13 -> dst
> 80.80.80.66
> 
> I understand that this is now expected functionality in the 2.6.11+
> kernels.

Yes, this is the new DNAT behaviour in the OUTPUT chain. It has good and 
bad sides. But I do not think your problem is related to this. The 
OUTPUT chain has effect only on locally generated packets, not on 
forwarded packets.

> Here is something that I derived from an older config, but obviously the
> POSTROUTING isn't working.
> 
> -A PREROUTING -d 80.80.80.66 -p tcp -m tcp --dport 53     -j DNAT
> --to-destination 10.40.0.13:53
> -A PREROUTING -d 80.80.80.66 -p udp -m udp --dport 53     -j DNAT
> --to-destination 10.40.0.13:53

I guess 10.40.0.13 is your primary (master) DNS server.

[...]
> -A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p tcp -m tcp --sport 53 -j
> SNAT --to-source 80.80.80.66:53
> -A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p udp -m udp --sport 53 -j
> SNAT --to-source 80.80.80.66:53

What do you expect these two rules to do ?

> -A POSTROUTING -o eth0 -j MASQUERADE

Ok.

> -A OUTPUT -d 80.80.80.66 -p tcp -m tcp --dport 53 -j DNAT
> --to-destination 10.40.0.13:53
> -A OUTPUT -d 80.80.80.66 -p udp -m udp --dport 53 -j DNAT
> --to-destination 10.40.0.13:53

Same question as above.

If you want inbound connections from the inside to 80.80.80.66:53 to be 
successfully redirected to 10.40.0.13, you need three things :
- the DNAT rules as above ;
- SNAT rules so that the DNATed connection will appear as coming from an 
specific external IP address. Your SNAT rules won't match the 
connections, you need --dport 53 instead of --sport 53 and do not need 
to change the source port into 53 ;
- and of course, ACCEPT packets from the internal interface back to the 
internal interface in the FORWARD chain.

For TCP, assuming the internal interface is eth1 :

-t nat -A PREROUTING -d 80.80.80.66 -p tcp --dport 53 \
   -j DNAT --to-destination 10.40.0.13
-t nat -A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p tcp --dport 53 \
   -j SNAT --to-source 80.80.80.66
-t filter -A FORWARD -i eth1 -o eth1 -j ACCEPT

For zone transfers to work through this redirection, you may need to 
tune your DNS servers setup also.

RE: Need to solve a NAT problem, any takers.

[Gary W. Smith]

> 
> Just being curious : why do you want to replicate the external view on
> the slave DNS server ? If I understand correctly, only the primary DNS
> server is reachable from the outside.
> 

Um, I can't remember :).  But that's a good question. 

> [...]
> > -A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p tcp -m tcp --sport
53 -j
> > SNAT --to-source 80.80.80.66:53
> > -A POSTROUTING -s 10.40.0.0/24 -d 10.40.0.13 -p udp -m udp --sport
53 -j
> > SNAT --to-source 80.80.80.66:53
> 
> What do you expect these two rules to do ?

A long long time ago I had to put these in to fix some VPN clients from
dying on the routes.  This was a long time ago though.  Since then for
our primary firewall we switched from NAT to bridging so we have since
not used most of the options.  So it's like relearning NAT'ing again

Anyways, thanks for the information.  I'll play around with this a
little more.

Re: Need to solve a NAT problem, any takers.

[Grant Taylor]

On 01/11/07 21:35, Gary W. Smith wrote:
> Internally our DNS server are split giving us internal IP's when queried
> internally and external's when queried externally.  This works fine.
> Our second DNS server internally slaves the primary.  Because we are
> using this split functionality when it slaves the internal IP's it gets
> the internal IP configuration.  Works great.  But in order to replicate
> the external range it must do so by replicating from the external IP.
> This fails at the IP's is NAT'd in by port only.  Years ago we solved
> this by running a second POSTROUTING rule and an OUTPUT rule on the
> firewall.  When I load these rules now 

I know this is not an IPTables / NAT answer, but I think it may possibly 
be an answer to your need.  What if you add a different subnet to your 
two DNS servers that each of them consider to be for the external view. 
  Tell your secondary to contact the primary on it's IP in this external 
view subnet.

Just a thought.



Grant. . . .

RE: Need to solve a NAT problem, any takers.

[Gary W. Smith]

Grant,

That would definitely solve the DNS part of the problem.  

Pascal Hambourg questioned why I really need to replicate the external
view to an internally only machine.  After we sat down today we found
that this really didn't need to be done as the secondary DNS server is
colocated somewhere else.  The internal lookup could never really happen
on the internal network with the confirmation that it's in now.  As long
as our internal DNS never references the external block we are fine.

FWIW it would be nice to be able to hit the public IP from within the
firewall but it's not the end of the world in this case.

Gary Wayne Smith

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Grant Taylor
> Sent: Friday, January 12, 2007 9:45 PM
> To: Mail List - Netfilter
> Subject: Re: Need to solve a NAT problem, any takers.
> 
> On 01/11/07 21:35, Gary W. Smith wrote:
> > Internally our DNS server are split giving us internal IP's when
queried
> > internally and external's when queried externally.  This works fine.
> > Our second DNS server internally slaves the primary.  Because we are
> > using this split functionality when it slaves the internal IP's it
gets
> > the internal IP configuration.  Works great.  But in order to
replicate
> > the external range it must do so by replicating from the external
IP.
> > This fails at the IP's is NAT'd in by port only.  Years ago we
solved
> > this by running a second POSTROUTING rule and an OUTPUT rule on the
> > firewall.  When I load these rules now
> 
> I know this is not an IPTables / NAT answer, but I think it may
possibly
> be an answer to your need.  What if you add a different subnet to your
> two DNS servers that each of them consider to be for the external
view.
>   Tell your secondary to contact the primary on it's IP in this
external
> view subnet.
> 
> Just a thought.
> 
> 
> 
> Grant. . . .