Internal machines can't resolve external addresses

Internal machines can't resolve external addresses

[Michael Hudin]

[-- Attachment #1: Type: text/plain, Size: 2503 bytes --]

Machines in the outside world, can view my websites fine, but whenever I try to go to one of them from a machine on my internal network behind the firewall, neither the domain name nor the IP will resolve.  I also have the same problem with my mail server and have to use the internal address of the mail server.  I am going to guess that the best solution to this is to run some kind of local DNS server on the inside of the firewall which resolves all my sites internally, but since I don't have a server at my disposal for it, is there some way around this?  I had the POSTROUTING MASQ line on and that did allow the internal machines to resolve, but it also hid the originating address for any outside machine, thus creating a security disaster.

-michael

*nat
:PREROUTING ACCEPT [241:88600]
:POSTROUTING ACCEPT [0:9862]
:OUTPUT ACCEPT [68:4275]
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.77.2
-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
#-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT

*mangle
:PREROUTING ACCEPT [18365:3221456]
:INPUT ACCEPT [10886:760348]
:FORWARD ACCEPT [7269:2438049]
:OUTPUT ACCEPT [8009:752540]
:POSTROUTING ACCEPT [15177:3182145]
COMMIT

*filter
:INPUT ACCEPT [0:229546]
:FORWARD ACCEPT [363:1553786]
:OUTPUT ACCEPT [2:619341]
-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A INPUT -p tcp -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A OUTPUT -p tcp -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT


[-- Attachment #2: Type: text/html, Size: 3313 bytes --]

Re: Internal machines can't resolve external addresses

[Matthew Hellman]

There is potentially another solution if you don't want to run your own bind
server.  Add a third nic to your firewall and put these boxes in a DMZ.
Then you can use PREROUTING/DNAT.

Goodluck,
Matt

----- Original Message -----
From: "Michael Hudin" <hudin@zoetrope.com>
To: <netfilter@lists.samba.org>
Sent: Tuesday, June 11, 2002 10:00 PM
Subject: Internal machines can't resolve external addresses


Machines in the outside world, can view my websites fine, but whenever I try
to go to one of them from a machine on my internal network behind the
firewall, neither the domain name nor the IP will resolve.  I also have the
same problem with my mail server and have to use the internal address of the
mail server.  I am going to guess that the best solution to this is to run
some kind of local DNS server on the inside of the firewall which resolves
all my sites internally, but since I don't have a server at my disposal for
it, is there some way around this?  I had the POSTROUTING MASQ line on and
that did allow the internal machines to resolve, but it also hid the
originating address for any outside machine, thus creating a security
disaster.

-michael

*nat
:PREROUTING ACCEPT [241:88600]
:POSTROUTING ACCEPT [0:9862]
:OUTPUT ACCEPT [68:4275]
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
DNAT --to-destination 192.168.77.2
-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
#-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT

*mangle
:PREROUTING ACCEPT [18365:3221456]
:INPUT ACCEPT [10886:760348]
:FORWARD ACCEPT [7269:2438049]
:OUTPUT ACCEPT [8009:752540]
:POSTROUTING ACCEPT [15177:3182145]
COMMIT

*filter
:INPUT ACCEPT [0:229546]
:FORWARD ACCEPT [363:1553786]
:OUTPUT ACCEPT [2:619341]
-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A INPUT -p tcp -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A OUTPUT -p tcp -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT

RE: Internal machines can't resolve external addresses

[Glover George]

Yes I've come across this problem MANY MANY times before, and would
appreciate it if someone could explain exactly why this doesn't work.
For instance.  I have 3 machines, a firewall/nat (linux), a linux
webserver and a windows machine behind it.  Now I am serving a website
that is on the webserver behind the firewall, and it's dns stuff is
somewhere out on the internet.  On my windows machine it resolves to the
public interface of the firewall.  Why doesn't packets destined for that
machine realize that they must be sent to the webserver instead of out
on the public interface? I know it's because the DNAT rule is on the
prerouting of the external nic, but why doesn't simply putting a DNAT
rule on the internal work as well?  

The only way for me to get this working is to run bind 9 and set up two
different views, to resolve different ip addresses whether you're on the
internet, or in my internal network.  But this is a hack, and everytime
I add someones website, I have to make changes to both views on the DNS
server to get it to work, for every host in that new domain.  It seems
like there should be an easier way, as I'm sure a LOT of people on this
list come across the same problem before.

May not be possible with the current nat framework, but was just
wondering if someone could elaborate on it.  As always, thanks in
advance.

Glover George
Systems/Networks Administrator
Gulf Sales & Supply, Inc.
dime@gulfsales.com
(228)-762-0268


-----Original Message-----
From: netfilter-admin@lists.samba.org
[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
Sent: Wednesday, June 12, 2002 7:30 AM
To: Michael Hudin; netfilter@lists.samba.org
Subject: Re: Internal machines can't resolve external addresses

There is potentially another solution if you don't want to run your own
bind
server.  Add a third nic to your firewall and put these boxes in a DMZ.
Then you can use PREROUTING/DNAT.

Goodluck,
Matt

----- Original Message -----
From: "Michael Hudin" <hudin@zoetrope.com>
To: <netfilter@lists.samba.org>
Sent: Tuesday, June 11, 2002 10:00 PM
Subject: Internal machines can't resolve external addresses


Machines in the outside world, can view my websites fine, but whenever I
try
to go to one of them from a machine on my internal network behind the
firewall, neither the domain name nor the IP will resolve.  I also have
the
same problem with my mail server and have to use the internal address of
the
mail server.  I am going to guess that the best solution to this is to
run
some kind of local DNS server on the inside of the firewall which
resolves
all my sites internally, but since I don't have a server at my disposal
for
it, is there some way around this?  I had the POSTROUTING MASQ line on
and
that did allow the internal machines to resolve, but it also hid the
originating address for any outside machine, thus creating a security
disaster.

-michael

*nat
:PREROUTING ACCEPT [241:88600]
:POSTROUTING ACCEPT [0:9862]
:OUTPUT ACCEPT [68:4275]
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
DNAT --to-destination 192.168.77.2
-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
DNAT --to-destination 192.168.77.2
-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
#-A POSTROUTING -o eth1 -j MASQUERADE
COMMIT

*mangle
:PREROUTING ACCEPT [18365:3221456]
:INPUT ACCEPT [10886:760348]
:FORWARD ACCEPT [7269:2438049]
:OUTPUT ACCEPT [8009:752540]
:POSTROUTING ACCEPT [15177:3182145]
COMMIT

*filter
:INPUT ACCEPT [0:229546]
:FORWARD ACCEPT [363:1553786]
:OUTPUT ACCEPT [2:619341]
-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A INPUT -p tcp -j ACCEPT
-A INPUT -p esp -j ACCEPT
-A INPUT -p ah -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A FORWARD -i eth1 -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
-A OUTPUT -p tcp -j ACCEPT
-A OUTPUT -p esp -j ACCEPT
-A OUTPUT -p ah -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT

Re: Internal machines can't resolve external addresses

[Ramin Alidousti]

On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:

> Yes I've come across this problem MANY MANY times before, and would
> appreciate it if someone could explain exactly why this doesn't work.
> For instance.  I have 3 machines, a firewall/nat (linux), a linux
> webserver and a windows machine behind it.  Now I am serving a website
> that is on the webserver behind the firewall, and it's dns stuff is
> somewhere out on the internet.  On my windows machine it resolves to the
> public interface of the firewall.  Why doesn't packets destined for that
> machine realize that they must be sent to the webserver instead of out
> on the public interface? I know it's because the DNAT rule is on the
> prerouting of the external nic, but why doesn't simply putting a DNAT
> rule on the internal work as well?  

Think logically. It's very obvious why it doesn't work.

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

Ramin

> 
> The only way for me to get this working is to run bind 9 and set up two
> different views, to resolve different ip addresses whether you're on the
> internet, or in my internal network.  But this is a hack, and everytime
> I add someones website, I have to make changes to both views on the DNS
> server to get it to work, for every host in that new domain.  It seems
> like there should be an easier way, as I'm sure a LOT of people on this
> list come across the same problem before.
> 
> May not be possible with the current nat framework, but was just
> wondering if someone could elaborate on it.  As always, thanks in
> advance.
> 
> Glover George
> Systems/Networks Administrator
> Gulf Sales & Supply, Inc.
> dime@gulfsales.com
> (228)-762-0268

Re: Internal machines can't resolve external addresses

[Antony Stone]

On Wednesday 12 June 2002 4:07 pm, Glover George wrote:

> Yes I've come across this problem MANY MANY times before, and would
> appreciate it if someone could explain exactly why this doesn't work.
> For instance.  I have 3 machines, a firewall/nat (linux), a linux
> webserver and a windows machine behind it.  Now I am serving a website
> that is on the webserver behind the firewall, and it's dns stuff is
> somewhere out on the internet.  On my windows machine it resolves to the
> public interface of the firewall.  Why doesn't packets destined for that
> machine realize that they must be sent to the webserver instead of out
> on the public interface?

They do.

The problem is the reply packets.

Your windows machine has a local network address.   It tries to contact the 
public address of the webserver, goes through the firewall (default route), 
gets DNATted to the private address of the webserver... so far no problem.

Then the webserver replies to the local address of the windows machine - ooh, 
it's local, therefore it doesn't have to go through the firewall, therefore 
it doesn't get reverse NATted by netfilter.

So your windows machine contact a public address and gets a reply from a 
local machine.   Doesn't like it, therefore no connection.

 

Hope this helps.

 

Antony.

RE: Internal machines can't resolve external addresses

[Glover George]

Thank you for the explanation.  By far much better than "think
logically" as someone else puts it.  You know if you think a questions
is stupid, don't answer it.

Glover George
Systems/Networks Administrator
Gulf Sales & Supply, Inc.
dime@gulfsales.com
(228)-762-0268


-----Original Message-----
From: netfilter-admin@lists.samba.org
[mailto:netfilter-admin@lists.samba.org] On Behalf Of Antony Stone
Sent: Wednesday, June 12, 2002 10:16 AM
To: netfilter@lists.samba.org
Subject: Re: Internal machines can't resolve external addresses

On Wednesday 12 June 2002 4:07 pm, Glover George wrote:

> Yes I've come across this problem MANY MANY times before, and would
> appreciate it if someone could explain exactly why this doesn't work.
> For instance.  I have 3 machines, a firewall/nat (linux), a linux
> webserver and a windows machine behind it.  Now I am serving a website
> that is on the webserver behind the firewall, and it's dns stuff is
> somewhere out on the internet.  On my windows machine it resolves to
the
> public interface of the firewall.  Why doesn't packets destined for
that
> machine realize that they must be sent to the webserver instead of out
> on the public interface?

They do.

The problem is the reply packets.

Your windows machine has a local network address.   It tries to contact
the 
public address of the webserver, goes through the firewall (default
route), 
gets DNATted to the private address of the webserver... so far no
problem.

Then the webserver replies to the local address of the windows machine -
ooh, 
it's local, therefore it doesn't have to go through the firewall,
therefore 
it doesn't get reverse NATted by netfilter.

So your windows machine contact a public address and gets a reply from a

local machine.   Doesn't like it, therefore no connection.

 

Hope this helps.

 

Antony.

Re: Internal machines can't resolve external addresses

[Ramin Alidousti]

On Wed, Jun 12, 2002 at 11:48:46AM -0500, Glover George wrote:

> Thank you for the explanation.  By far much better than "think
> logically" as someone else puts it.  You know if you think a questions

Sorry if I stepped on the toes by saying "think logically". OK, don't
think logically but at least read the FAQ's and HowTo's which are
provided just for that reason...before posting this kind of questions.

I think we need a banner for all the posting which urges the users
to take their time by reading the docs first. A third of the postings
would not get posted if they did.

Antony, how often did you answer this very question?

Ramin

> is stupid, don't answer it.
> 
> Glover George
> Systems/Networks Administrator
> Gulf Sales & Supply, Inc.
> dime@gulfsales.com
> (228)-762-0268

Re: Internal machines can't resolve external addresses

[Antony Stone]

On Wednesday 12 June 2002 6:28 pm, Ramin Alidousti wrote:

> I think we need a banner for all the posting which urges the users
> to take their time by reading the docs first. A third of the postings
> would not get posted if they did.

Sorry, but I don't think that will work.   The FAQs are there - they're 
announced on the same website where people find the address of this mailing 
list to subscribe and post messages.   If they haven't read the FAQs (or 
understood the bit which relates to their question) by the time they get 
here, I don't think anything else is going to stop them posting what we might 
think is a simple question with a logical answer, but enough other people 
clearly can't work out for themselves (that's not a criticism - I'm saying 
people are thick - I'm just saying that they haven't been able to figure out 
the answer for themselves, therefore they post the question here).

> Antony, how often did you answer this very question?

Yes, you're right - exactly the same question from several different people 
over the past few weeks.   I'm tempted to put the answer on one of my web 
pages and just reply with the URL from now on.


 

Antony.

Re: Internal machines can't resolve external addresses

[Ramin Alidousti]

On Wed, Jun 12, 2002 at 08:59:10PM +0100, Antony Stone wrote:

> > Antony, how often did you answer this very question?
> 
> Yes, you're right - exactly the same question from several different people 
> over the past few weeks.   I'm tempted to put the answer on one of my web 
> pages and just reply with the URL from now on.

No need for that. This is already done in the HowTo:

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

Ramin

> Antony.

RE: Internal machines can't resolve external addresses

[Glover George]

No actually what would be nicer is the ability to search the list.
IIRC, you can't.  Al you can do is sort.  This is why people don't want
to read through previous posts.  Also, I did read the HOWTO a while back
(years) when I first started doing this.  My point was that I KNOW it
doesn't work.  But was asking for details and wondering if people could
pipe in on how it might be done successfully in the future.

Glover George
Systems/Networks Administrator
Gulf Sales & Supply, Inc.
dime@gulfsales.com
(228)-762-0268


-----Original Message-----
From: netfilter-admin@lists.samba.org
[mailto:netfilter-admin@lists.samba.org] On Behalf Of Ramin Alidousti
Sent: Wednesday, June 12, 2002 3:02 PM
To: Antony Stone
Cc: netfilter@lists.samba.org
Subject: Re: Internal machines can't resolve external addresses

On Wed, Jun 12, 2002 at 08:59:10PM +0100, Antony Stone wrote:

> > Antony, how often did you answer this very question?
> 
> Yes, you're right - exactly the same question from several different
people 
> over the past few weeks.   I'm tempted to put the answer on one of my
web 
> pages and just reply with the URL from now on.

No need for that. This is already done in the HowTo:

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-10.html

Ramin

> Antony.

Re: Internal machines can't resolve external addresses

[George Georgalis]

The request gets the the public interface, then (presumably, depends on
your rules) goes to the LAN server and is answered to the client IP,
which is listening for the response from the public IP, no go.

The LAN server needs to be be on a different subnet, so all traffic is
routed through the router.

You could remove the host route to the LAN, leaving only the route to
the firewall, then you'll have the same problem if you access the LAN
host via private IP.

(Corrections welcome ;-)

// George

On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:
>Yes I've come across this problem MANY MANY times before, and would
>appreciate it if someone could explain exactly why this doesn't work.
>For instance.  I have 3 machines, a firewall/nat (linux), a linux
>webserver and a windows machine behind it.  Now I am serving a website
>that is on the webserver behind the firewall, and it's dns stuff is
>somewhere out on the internet.  On my windows machine it resolves to the
>public interface of the firewall.  Why doesn't packets destined for that
>machine realize that they must be sent to the webserver instead of out
>on the public interface? I know it's because the DNAT rule is on the
>prerouting of the external nic, but why doesn't simply putting a DNAT
>rule on the internal work as well?  
>
>The only way for me to get this working is to run bind 9 and set up two
>different views, to resolve different ip addresses whether you're on the
>internet, or in my internal network.  But this is a hack, and everytime
>I add someones website, I have to make changes to both views on the DNS
>server to get it to work, for every host in that new domain.  It seems
>like there should be an easier way, as I'm sure a LOT of people on this
>list come across the same problem before.
>
>May not be possible with the current nat framework, but was just
>wondering if someone could elaborate on it.  As always, thanks in
>advance.
>
>Glover George
>Systems/Networks Administrator
>Gulf Sales & Supply, Inc.
>dime@gulfsales.com
>(228)-762-0268
>
>
>-----Original Message-----
>From: netfilter-admin@lists.samba.org
>[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
>Sent: Wednesday, June 12, 2002 7:30 AM
>To: Michael Hudin; netfilter@lists.samba.org
>Subject: Re: Internal machines can't resolve external addresses
>
>There is potentially another solution if you don't want to run your own
>bind
>server.  Add a third nic to your firewall and put these boxes in a DMZ.
>Then you can use PREROUTING/DNAT.
>
>Goodluck,
>Matt
>
>----- Original Message -----
>From: "Michael Hudin" <hudin@zoetrope.com>
>To: <netfilter@lists.samba.org>
>Sent: Tuesday, June 11, 2002 10:00 PM
>Subject: Internal machines can't resolve external addresses
>
>
>Machines in the outside world, can view my websites fine, but whenever I
>try
>to go to one of them from a machine on my internal network behind the
>firewall, neither the domain name nor the IP will resolve.  I also have
>the
>same problem with my mail server and have to use the internal address of
>the
>mail server.  I am going to guess that the best solution to this is to
>run
>some kind of local DNS server on the inside of the firewall which
>resolves
>all my sites internally, but since I don't have a server at my disposal
>for
>it, is there some way around this?  I had the POSTROUTING MASQ line on
>and
>that did allow the internal machines to resolve, but it also hid the
>originating address for any outside machine, thus creating a security
>disaster.
>
>-michael
>
>*nat
>:PREROUTING ACCEPT [241:88600]
>:POSTROUTING ACCEPT [0:9862]
>:OUTPUT ACCEPT [68:4275]
>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
>DNAT --to-destination 192.168.77.2
>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
>DNAT --to-destination 192.168.77.2
>-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
>DNAT --to-destination 192.168.77.2
>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
>DNAT --to-destination 192.168.77.2
>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
>DNAT --to-destination 192.168.77.2
>-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
>#-A POSTROUTING -o eth1 -j MASQUERADE
>COMMIT
>
>*mangle
>:PREROUTING ACCEPT [18365:3221456]
>:INPUT ACCEPT [10886:760348]
>:FORWARD ACCEPT [7269:2438049]
>:OUTPUT ACCEPT [8009:752540]
>:POSTROUTING ACCEPT [15177:3182145]
>COMMIT
>
>*filter
>:INPUT ACCEPT [0:229546]
>:FORWARD ACCEPT [363:1553786]
>:OUTPUT ACCEPT [2:619341]
>-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>-A INPUT -p tcp -j ACCEPT
>-A INPUT -p esp -j ACCEPT
>-A INPUT -p ah -j ACCEPT
>-A INPUT -i lo -j ACCEPT
>-A FORWARD -i eth1 -j ACCEPT
>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
>NEW,RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
>NEW,RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
>NEW,RELATED,ESTABLISHED -j ACCEPT
>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
>NEW,RELATED,ESTABLISHED -j ACCEPT
>-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>-A OUTPUT -p tcp -j ACCEPT
>-A OUTPUT -p esp -j ACCEPT
>-A OUTPUT -p ah -j ACCEPT
>-A OUTPUT -o lo -j ACCEPT
>COMMIT
>
>
>
>
>
>
>
>

-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:george@galis.org 
File, Print, DB and DNS Servers.       http://www.galis.org/george 

Re: Internal machines can't resolve external addresses

[George Georgalis]

Oops, forgot to mention the solution I'm using... which Ramin directed
me to :)

DNS. I'm using tinydns/dnscache which answers LAN lookups with LAN IPs
and public lookups with public IPs. http://cr.yp.to/djbdns/install.html

Here are relevant lines from my zone data file...


### Client location conditional expressions
%LL:192.168
%LL:127

### SOA, NS and A definitions
.local:192.168.5.5:a:259200:LL
.168.192.in-addr.arpa:192.168.5.5:a:259200:LL
.domain.com:88.77.66.55:a:259200
.66.77.88.in-addr.arpa:88.77.66.55:a:259200

### PTR and A for LAN locals
=www.local:192.168.6.6:86400:LL
=mail.local:192.168.7.7:86400:LL

### PTR and A for Public
=www.domain.com:88.77.66.56:86400
=mail.domain.com:88.77.66.57:86400


(BTW - easier to configure than bind, eh? Not sure which Ramin
recommends.)

// George

On Wed, Jun 12, 2002 at 11:34:41AM -0400, George Georgalis wrote:
>The request gets the the public interface, then (presumably, depends on
>your rules) goes to the LAN server and is answered to the client IP,
>which is listening for the response from the public IP, no go.
>
>The LAN server needs to be be on a different subnet, so all traffic is
>routed through the router.
>
>You could remove the host route to the LAN, leaving only the route to
>the firewall, then you'll have the same problem if you access the LAN
>host via private IP.
>
>(Corrections welcome ;-)
>
>// George
>
>On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:
>>Yes I've come across this problem MANY MANY times before, and would
>>appreciate it if someone could explain exactly why this doesn't work.
>>For instance.  I have 3 machines, a firewall/nat (linux), a linux
>>webserver and a windows machine behind it.  Now I am serving a website
>>that is on the webserver behind the firewall, and it's dns stuff is
>>somewhere out on the internet.  On my windows machine it resolves to the
>>public interface of the firewall.  Why doesn't packets destined for that
>>machine realize that they must be sent to the webserver instead of out
>>on the public interface? I know it's because the DNAT rule is on the
>>prerouting of the external nic, but why doesn't simply putting a DNAT
>>rule on the internal work as well?  
>>
>>The only way for me to get this working is to run bind 9 and set up two
>>different views, to resolve different ip addresses whether you're on the
>>internet, or in my internal network.  But this is a hack, and everytime
>>I add someones website, I have to make changes to both views on the DNS
>>server to get it to work, for every host in that new domain.  It seems
>>like there should be an easier way, as I'm sure a LOT of people on this
>>list come across the same problem before.
>>
>>May not be possible with the current nat framework, but was just
>>wondering if someone could elaborate on it.  As always, thanks in
>>advance.
>>
>>Glover George
>>Systems/Networks Administrator
>>Gulf Sales & Supply, Inc.
>>dime@gulfsales.com
>>(228)-762-0268
>>
>>
>>-----Original Message-----
>>From: netfilter-admin@lists.samba.org
>>[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
>>Sent: Wednesday, June 12, 2002 7:30 AM
>>To: Michael Hudin; netfilter@lists.samba.org
>>Subject: Re: Internal machines can't resolve external addresses
>>
>>There is potentially another solution if you don't want to run your own
>>bind
>>server.  Add a third nic to your firewall and put these boxes in a DMZ.
>>Then you can use PREROUTING/DNAT.
>>
>>Goodluck,
>>Matt
>>
>>----- Original Message -----
>>From: "Michael Hudin" <hudin@zoetrope.com>
>>To: <netfilter@lists.samba.org>
>>Sent: Tuesday, June 11, 2002 10:00 PM
>>Subject: Internal machines can't resolve external addresses
>>
>>
>>Machines in the outside world, can view my websites fine, but whenever I
>>try
>>to go to one of them from a machine on my internal network behind the
>>firewall, neither the domain name nor the IP will resolve.  I also have
>>the
>>same problem with my mail server and have to use the internal address of
>>the
>>mail server.  I am going to guess that the best solution to this is to
>>run
>>some kind of local DNS server on the inside of the firewall which
>>resolves
>>all my sites internally, but since I don't have a server at my disposal
>>for
>>it, is there some way around this?  I had the POSTROUTING MASQ line on
>>and
>>that did allow the internal machines to resolve, but it also hid the
>>originating address for any outside machine, thus creating a security
>>disaster.
>>
>>-michael
>>
>>*nat
>>:PREROUTING ACCEPT [241:88600]
>>:POSTROUTING ACCEPT [0:9862]
>>:OUTPUT ACCEPT [68:4275]
>>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
>>DNAT --to-destination 192.168.77.2
>>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
>>DNAT --to-destination 192.168.77.2
>>-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
>>DNAT --to-destination 192.168.77.2
>>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
>>DNAT --to-destination 192.168.77.2
>>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
>>DNAT --to-destination 192.168.77.2
>>-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
>>#-A POSTROUTING -o eth1 -j MASQUERADE
>>COMMIT
>>
>>*mangle
>>:PREROUTING ACCEPT [18365:3221456]
>>:INPUT ACCEPT [10886:760348]
>>:FORWARD ACCEPT [7269:2438049]
>>:OUTPUT ACCEPT [8009:752540]
>>:POSTROUTING ACCEPT [15177:3182145]
>>COMMIT
>>
>>*filter
>>:INPUT ACCEPT [0:229546]
>>:FORWARD ACCEPT [363:1553786]
>>:OUTPUT ACCEPT [2:619341]
>>-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>>-A INPUT -p tcp -j ACCEPT
>>-A INPUT -p esp -j ACCEPT
>>-A INPUT -p ah -j ACCEPT
>>-A INPUT -i lo -j ACCEPT
>>-A FORWARD -i eth1 -j ACCEPT
>>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
>>NEW,RELATED,ESTABLISHED -j ACCEPT
>>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
>>NEW,RELATED,ESTABLISHED -j ACCEPT
>>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
>>NEW,RELATED,ESTABLISHED -j ACCEPT
>>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
>>NEW,RELATED,ESTABLISHED -j ACCEPT
>>-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>>-A OUTPUT -p tcp -j ACCEPT
>>-A OUTPUT -p esp -j ACCEPT
>>-A OUTPUT -p ah -j ACCEPT
>>-A OUTPUT -o lo -j ACCEPT
>>COMMIT
>>
>>
>>
>>
>>
>>
>>
>>
>
>-- 
>GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
>Security Services, Web, Mail,            mailto:george@galis.org 
>File, Print, DB and DNS Servers.       http://www.galis.org/george 
>

-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:george@galis.org 
File, Print, DB and DNS Servers.       http://www.galis.org/george 

Re: Internal machines can't resolve external addresses

[Michael Hudin]

So, there isn't any kind of aliasing or PREROUTING you can do for individual
machines?  You couldn't take any requests to port 80 or 25 and FORWARD then
to the outside interface? Wait, I guess not since a client is sending its
request to the server on a port above 1024.

I guess if this is the way it is, then that's that and I'll have to learn
DNS a lot sooner than I had hoped.

Hey is this in the FAQ or any of the site documentation anywhere?  If not, I
do a lot of technical writing and would be more than happy to draft
something up since apparently a lot of people have this problem.

-michael

----- Original Message -----
From: "George Georgalis" <georgw@galis.org>
To: <netfilter@lists.samba.org>
Sent: Wednesday, June 12, 2002 8:58 AM
Subject: Re: Internal machines can't resolve external addresses


> Oops, forgot to mention the solution I'm using... which Ramin directed
> me to :)
>
> DNS. I'm using tinydns/dnscache which answers LAN lookups with LAN IPs
> and public lookups with public IPs. http://cr.yp.to/djbdns/install.html
>
> Here are relevant lines from my zone data file...
>
>
> ### Client location conditional expressions
> %LL:192.168
> %LL:127
>
> ### SOA, NS and A definitions
> .local:192.168.5.5:a:259200:LL
> .168.192.in-addr.arpa:192.168.5.5:a:259200:LL
> .domain.com:88.77.66.55:a:259200
> .66.77.88.in-addr.arpa:88.77.66.55:a:259200
>
> ### PTR and A for LAN locals
> =www.local:192.168.6.6:86400:LL
> =mail.local:192.168.7.7:86400:LL
>
> ### PTR and A for Public
> =www.domain.com:88.77.66.56:86400
> =mail.domain.com:88.77.66.57:86400
>
>
> (BTW - easier to configure than bind, eh? Not sure which Ramin
> recommends.)
>
> // George
>
> On Wed, Jun 12, 2002 at 11:34:41AM -0400, George Georgalis wrote:
> >The request gets the the public interface, then (presumably, depends on
> >your rules) goes to the LAN server and is answered to the client IP,
> >which is listening for the response from the public IP, no go.
> >
> >The LAN server needs to be be on a different subnet, so all traffic is
> >routed through the router.
> >
> >You could remove the host route to the LAN, leaving only the route to
> >the firewall, then you'll have the same problem if you access the LAN
> >host via private IP.
> >
> >(Corrections welcome ;-)
> >
> >// George
> >
> >On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:
> >>Yes I've come across this problem MANY MANY times before, and would
> >>appreciate it if someone could explain exactly why this doesn't work.
> >>For instance.  I have 3 machines, a firewall/nat (linux), a linux
> >>webserver and a windows machine behind it.  Now I am serving a website
> >>that is on the webserver behind the firewall, and it's dns stuff is
> >>somewhere out on the internet.  On my windows machine it resolves to the
> >>public interface of the firewall.  Why doesn't packets destined for that
> >>machine realize that they must be sent to the webserver instead of out
> >>on the public interface? I know it's because the DNAT rule is on the
> >>prerouting of the external nic, but why doesn't simply putting a DNAT
> >>rule on the internal work as well?
> >>
> >>The only way for me to get this working is to run bind 9 and set up two
> >>different views, to resolve different ip addresses whether you're on the
> >>internet, or in my internal network.  But this is a hack, and everytime
> >>I add someones website, I have to make changes to both views on the DNS
> >>server to get it to work, for every host in that new domain.  It seems
> >>like there should be an easier way, as I'm sure a LOT of people on this
> >>list come across the same problem before.
> >>
> >>May not be possible with the current nat framework, but was just
> >>wondering if someone could elaborate on it.  As always, thanks in
> >>advance.
> >>
> >>Glover George
> >>Systems/Networks Administrator
> >>Gulf Sales & Supply, Inc.
> >>dime@gulfsales.com
> >>(228)-762-0268
> >>
> >>
> >>-----Original Message-----
> >>From: netfilter-admin@lists.samba.org
> >>[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
> >>Sent: Wednesday, June 12, 2002 7:30 AM
> >>To: Michael Hudin; netfilter@lists.samba.org
> >>Subject: Re: Internal machines can't resolve external addresses
> >>
> >>There is potentially another solution if you don't want to run your own
> >>bind
> >>server.  Add a third nic to your firewall and put these boxes in a DMZ.
> >>Then you can use PREROUTING/DNAT.
> >>
> >>Goodluck,
> >>Matt
> >>
> >>----- Original Message -----
> >>From: "Michael Hudin" <hudin@zoetrope.com>
> >>To: <netfilter@lists.samba.org>
> >>Sent: Tuesday, June 11, 2002 10:00 PM
> >>Subject: Internal machines can't resolve external addresses
> >>
> >>
> >>Machines in the outside world, can view my websites fine, but whenever I
> >>try
> >>to go to one of them from a machine on my internal network behind the
> >>firewall, neither the domain name nor the IP will resolve.  I also have
> >>the
> >>same problem with my mail server and have to use the internal address of
> >>the
> >>mail server.  I am going to guess that the best solution to this is to
> >>run
> >>some kind of local DNS server on the inside of the firewall which
> >>resolves
> >>all my sites internally, but since I don't have a server at my disposal
> >>for
> >>it, is there some way around this?  I had the POSTROUTING MASQ line on
> >>and
> >>that did allow the internal machines to resolve, but it also hid the
> >>originating address for any outside machine, thus creating a security
> >>disaster.
> >>
> >>-michael
> >>
> >>*nat
> >>:PREROUTING ACCEPT [241:88600]
> >>:POSTROUTING ACCEPT [0:9862]
> >>:OUTPUT ACCEPT [68:4275]
> >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
> >>DNAT --to-destination 192.168.77.2
> >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
> >>DNAT --to-destination 192.168.77.2
> >>-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
> >>DNAT --to-destination 192.168.77.2
> >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
> >>DNAT --to-destination 192.168.77.2
> >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
> >>DNAT --to-destination 192.168.77.2
> >>-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
> >>#-A POSTROUTING -o eth1 -j MASQUERADE
> >>COMMIT
> >>
> >>*mangle
> >>:PREROUTING ACCEPT [18365:3221456]
> >>:INPUT ACCEPT [10886:760348]
> >>:FORWARD ACCEPT [7269:2438049]
> >>:OUTPUT ACCEPT [8009:752540]
> >>:POSTROUTING ACCEPT [15177:3182145]
> >>COMMIT
> >>
> >>*filter
> >>:INPUT ACCEPT [0:229546]
> >>:FORWARD ACCEPT [363:1553786]
> >>:OUTPUT ACCEPT [2:619341]
> >>-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> >>-A INPUT -p tcp -j ACCEPT
> >>-A INPUT -p esp -j ACCEPT
> >>-A INPUT -p ah -j ACCEPT
> >>-A INPUT -i lo -j ACCEPT
> >>-A FORWARD -i eth1 -j ACCEPT
> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
> >>NEW,RELATED,ESTABLISHED -j ACCEPT
> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
> >>NEW,RELATED,ESTABLISHED -j ACCEPT
> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
> >>NEW,RELATED,ESTABLISHED -j ACCEPT
> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
> >>NEW,RELATED,ESTABLISHED -j ACCEPT
> >>-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> >>-A OUTPUT -p tcp -j ACCEPT
> >>-A OUTPUT -p esp -j ACCEPT
> >>-A OUTPUT -p ah -j ACCEPT
> >>-A OUTPUT -o lo -j ACCEPT
> >>COMMIT
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >--
> >GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
> >Security Services, Web, Mail,            mailto:george@galis.org
> >File, Print, DB and DNS Servers.       http://www.galis.org/george
> >
>
> --
> GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
> Security Services, Web, Mail,            mailto:george@galis.org
> File, Print, DB and DNS Servers.       http://www.galis.org/george
>
>
>
>

Re: Internal machines can't resolve external addresses

[George Georgalis]

I would guess the category of this question is the most frequent on the
list :) It stumped me... anyway try djbdns (it's different, but EZ and
secure), if you get stuck you can email me or join the discussion list
on http://kernel-panic.org where my questions are answered faster than I
can check my mail :)

BTW - the data file I first posted returns both the local and public
IPs to LAN requests. this would be better... only returns public IPs to
external requests.

### Client location conditional expressions
%LL:192.168
%LL:127
%EX

### SOA, NS and A definitions
.local:192.168.5.5:a:259200:LL
.168.192.in-addr.arpa:192.168.5.5:a:259200:LL
.domain.com:88.77.66.55:a:259200:EX
.66.77.88.in-addr.arpa:88.77.66.55:a:259200:EX

### PTR and A for LAN locals
=www.local:192.168.6.6:86400:LL
=mail.local:192.168.7.7:86400:LL

### PTR and A for Public
=www.domain.com:88.77.66.56:86400:EX
=mail.domain.com:88.77.66.57:86400:EX



// George

On Wed, Jun 12, 2002 at 09:48:00AM -0700, Michael Hudin wrote:
>So, there isn't any kind of aliasing or PREROUTING you can do for individual
>machines?  You couldn't take any requests to port 80 or 25 and FORWARD then
>to the outside interface? Wait, I guess not since a client is sending its
>request to the server on a port above 1024.
>
>I guess if this is the way it is, then that's that and I'll have to learn
>DNS a lot sooner than I had hoped.
>
>Hey is this in the FAQ or any of the site documentation anywhere?  If not, I
>do a lot of technical writing and would be more than happy to draft
>something up since apparently a lot of people have this problem.
>
>-michael
>
>----- Original Message -----
>From: "George Georgalis" <georgw@galis.org>
>To: <netfilter@lists.samba.org>
>Sent: Wednesday, June 12, 2002 8:58 AM
>Subject: Re: Internal machines can't resolve external addresses
>
>
>> Oops, forgot to mention the solution I'm using... which Ramin directed
>> me to :)
>>
>> DNS. I'm using tinydns/dnscache which answers LAN lookups with LAN IPs
>> and public lookups with public IPs. http://cr.yp.to/djbdns/install.html
>>
>> Here are relevant lines from my zone data file...
>>
>>
>> ### Client location conditional expressions
>> %LL:192.168
>> %LL:127
>>
>> ### SOA, NS and A definitions
>> .local:192.168.5.5:a:259200:LL
>> .168.192.in-addr.arpa:192.168.5.5:a:259200:LL
>> .domain.com:88.77.66.55:a:259200
>> .66.77.88.in-addr.arpa:88.77.66.55:a:259200
>>
>> ### PTR and A for LAN locals
>> =www.local:192.168.6.6:86400:LL
>> =mail.local:192.168.7.7:86400:LL
>>
>> ### PTR and A for Public
>> =www.domain.com:88.77.66.56:86400
>> =mail.domain.com:88.77.66.57:86400
>>
>>
>> (BTW - easier to configure than bind, eh? Not sure which Ramin
>> recommends.)
>>
>> // George
>>
>> On Wed, Jun 12, 2002 at 11:34:41AM -0400, George Georgalis wrote:
>> >The request gets the the public interface, then (presumably, depends on
>> >your rules) goes to the LAN server and is answered to the client IP,
>> >which is listening for the response from the public IP, no go.
>> >
>> >The LAN server needs to be be on a different subnet, so all traffic is
>> >routed through the router.
>> >
>> >You could remove the host route to the LAN, leaving only the route to
>> >the firewall, then you'll have the same problem if you access the LAN
>> >host via private IP.
>> >
>> >(Corrections welcome ;-)
>> >
>> >// George
>> >
>> >On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:
>> >>Yes I've come across this problem MANY MANY times before, and would
>> >>appreciate it if someone could explain exactly why this doesn't work.
>> >>For instance.  I have 3 machines, a firewall/nat (linux), a linux
>> >>webserver and a windows machine behind it.  Now I am serving a website
>> >>that is on the webserver behind the firewall, and it's dns stuff is
>> >>somewhere out on the internet.  On my windows machine it resolves to the
>> >>public interface of the firewall.  Why doesn't packets destined for that
>> >>machine realize that they must be sent to the webserver instead of out
>> >>on the public interface? I know it's because the DNAT rule is on the
>> >>prerouting of the external nic, but why doesn't simply putting a DNAT
>> >>rule on the internal work as well?
>> >>
>> >>The only way for me to get this working is to run bind 9 and set up two
>> >>different views, to resolve different ip addresses whether you're on the
>> >>internet, or in my internal network.  But this is a hack, and everytime
>> >>I add someones website, I have to make changes to both views on the DNS
>> >>server to get it to work, for every host in that new domain.  It seems
>> >>like there should be an easier way, as I'm sure a LOT of people on this
>> >>list come across the same problem before.
>> >>
>> >>May not be possible with the current nat framework, but was just
>> >>wondering if someone could elaborate on it.  As always, thanks in
>> >>advance.
>> >>
>> >>Glover George
>> >>Systems/Networks Administrator
>> >>Gulf Sales & Supply, Inc.
>> >>dime@gulfsales.com
>> >>(228)-762-0268
>> >>
>> >>
>> >>-----Original Message-----
>> >>From: netfilter-admin@lists.samba.org
>> >>[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
>> >>Sent: Wednesday, June 12, 2002 7:30 AM
>> >>To: Michael Hudin; netfilter@lists.samba.org
>> >>Subject: Re: Internal machines can't resolve external addresses
>> >>
>> >>There is potentially another solution if you don't want to run your own
>> >>bind
>> >>server.  Add a third nic to your firewall and put these boxes in a DMZ.
>> >>Then you can use PREROUTING/DNAT.
>> >>
>> >>Goodluck,
>> >>Matt
>> >>
>> >>----- Original Message -----
>> >>From: "Michael Hudin" <hudin@zoetrope.com>
>> >>To: <netfilter@lists.samba.org>
>> >>Sent: Tuesday, June 11, 2002 10:00 PM
>> >>Subject: Internal machines can't resolve external addresses
>> >>
>> >>
>> >>Machines in the outside world, can view my websites fine, but whenever I
>> >>try
>> >>to go to one of them from a machine on my internal network behind the
>> >>firewall, neither the domain name nor the IP will resolve.  I also have
>> >>the
>> >>same problem with my mail server and have to use the internal address of
>> >>the
>> >>mail server.  I am going to guess that the best solution to this is to
>> >>run
>> >>some kind of local DNS server on the inside of the firewall which
>> >>resolves
>> >>all my sites internally, but since I don't have a server at my disposal
>> >>for
>> >>it, is there some way around this?  I had the POSTROUTING MASQ line on
>> >>and
>> >>that did allow the internal machines to resolve, but it also hid the
>> >>originating address for any outside machine, thus creating a security
>> >>disaster.
>> >>
>> >>-michael
>> >>
>> >>*nat
>> >>:PREROUTING ACCEPT [241:88600]
>> >>:POSTROUTING ACCEPT [0:9862]
>> >>:OUTPUT ACCEPT [68:4275]
>> >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
>> >>DNAT --to-destination 192.168.77.2
>> >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
>> >>DNAT --to-destination 192.168.77.2
>> >>-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
>> >>DNAT --to-destination 192.168.77.2
>> >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
>> >>DNAT --to-destination 192.168.77.2
>> >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
>> >>DNAT --to-destination 192.168.77.2
>> >>-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
>> >>#-A POSTROUTING -o eth1 -j MASQUERADE
>> >>COMMIT
>> >>
>> >>*mangle
>> >>:PREROUTING ACCEPT [18365:3221456]
>> >>:INPUT ACCEPT [10886:760348]
>> >>:FORWARD ACCEPT [7269:2438049]
>> >>:OUTPUT ACCEPT [8009:752540]
>> >>:POSTROUTING ACCEPT [15177:3182145]
>> >>COMMIT
>> >>
>> >>*filter
>> >>:INPUT ACCEPT [0:229546]
>> >>:FORWARD ACCEPT [363:1553786]
>> >>:OUTPUT ACCEPT [2:619341]
>> >>-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>> >>-A INPUT -p tcp -j ACCEPT
>> >>-A INPUT -p esp -j ACCEPT
>> >>-A INPUT -p ah -j ACCEPT
>> >>-A INPUT -i lo -j ACCEPT
>> >>-A FORWARD -i eth1 -j ACCEPT
>> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
>> >>NEW,RELATED,ESTABLISHED -j ACCEPT
>> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
>> >>NEW,RELATED,ESTABLISHED -j ACCEPT
>> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
>> >>NEW,RELATED,ESTABLISHED -j ACCEPT
>> >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
>> >>NEW,RELATED,ESTABLISHED -j ACCEPT
>> >>-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
>> >>-A OUTPUT -p tcp -j ACCEPT
>> >>-A OUTPUT -p esp -j ACCEPT
>> >>-A OUTPUT -p ah -j ACCEPT
>> >>-A OUTPUT -o lo -j ACCEPT
>> >>COMMIT
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >--
>> >GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
>> >Security Services, Web, Mail,            mailto:george@galis.org
>> >File, Print, DB and DNS Servers.       http://www.galis.org/george
>> >
>>
>> --
>> GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
>> Security Services, Web, Mail,            mailto:george@galis.org
>> File, Print, DB and DNS Servers.       http://www.galis.org/george
>>
>>
>>
>>
>
>

-- 
GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229 
Security Services, Web, Mail,            mailto:george@galis.org 
File, Print, DB and DNS Servers.       http://www.galis.org/george 

RE: Internal machines can't resolve external addresses

[Joe Patterson]

I believe the general case of this is often referred to as "hairpin nat"
The solution is to add an SNAT rule in nat/POSTROUTING that changes the
source to the internal interface ip of the firewall (although you could use
any external address for the source, it doesn't really matter.... but could
be confusing...)

I use a few functions that I whipped together for this:

IPT="debug /usr/local/sbin/iptables"
debug() {
        if [ -n "$debug" ]; then
                "$@" || echo -e "the above error was in reponse to the
command:\n$@"
        else
                "$@"
        fi
}
natin() {
        # usage is: natin (external ip) (internal ip) {tcp_ports}
{udp_ports}
        debug ip address delete $1 dev $EXT_INT
        $IPT -t nat -A PREROUTING -i $EXT_INT -d $1 -j DNAT --to $2
        debug ip address add $1 dev $EXT_INT
        [ -n $3 ] && $IPT -A EXT_IN -p tcp -m mport --dports $3 -d $2 -j
ACCEPT
        [ -n $4 ] && $IPT -A EXT_IN -p udp -m mport --dports $4 -d $2 -j
ACCEPT
        }
hairpin() {
        # usage same as natin, but does hairpin nat also
        debug ip address delete $1 dev $EXT_INT
        $IPT -t nat -A PREROUTING -d $1 -j DNAT --to $2
        debug ip address add $1 dev $EXT_INT
        $IPT -t nat -A POSTROUTING -d $2  -s $INT_NET -j SNAT --to $INT_IP
        [ -n $3 ] && $IPT -A EXT_IN -p tcp -m mport --dports $3 -d $2 -j
ACCEPT
        [ -n $4 ] && $IPT -A EXT_IN -p udp -m mport --dports $4 -d $2 -j
ACCEPT
        }

It's not perfect and doesn't cover all cases, but seems to work ok for
most...

-Joe

> -----Original Message-----
> From: netfilter-admin@lists.samba.org
> [mailto:netfilter-admin@lists.samba.org]On Behalf Of Michael Hudin
> Sent: Wednesday, June 12, 2002 12:48 PM
> To: netfilter@lists.samba.org
> Subject: Re: Internal machines can't resolve external addresses
>
>
> So, there isn't any kind of aliasing or PREROUTING you can do for
> individual
> machines?  You couldn't take any requests to port 80 or 25 and
> FORWARD then
> to the outside interface? Wait, I guess not since a client is sending its
> request to the server on a port above 1024.
>
> I guess if this is the way it is, then that's that and I'll have to learn
> DNS a lot sooner than I had hoped.
>
> Hey is this in the FAQ or any of the site documentation anywhere?
>  If not, I
> do a lot of technical writing and would be more than happy to draft
> something up since apparently a lot of people have this problem.
>
> -michael
>
> ----- Original Message -----
> From: "George Georgalis" <georgw@galis.org>
> To: <netfilter@lists.samba.org>
> Sent: Wednesday, June 12, 2002 8:58 AM
> Subject: Re: Internal machines can't resolve external addresses
>
>
> > Oops, forgot to mention the solution I'm using... which Ramin directed
> > me to :)
> >
> > DNS. I'm using tinydns/dnscache which answers LAN lookups with LAN IPs
> > and public lookups with public IPs. http://cr.yp.to/djbdns/install.html
> >
> > Here are relevant lines from my zone data file...
> >
> >
> > ### Client location conditional expressions
> > %LL:192.168
> > %LL:127
> >
> > ### SOA, NS and A definitions
> > .local:192.168.5.5:a:259200:LL
> > .168.192.in-addr.arpa:192.168.5.5:a:259200:LL
> > .domain.com:88.77.66.55:a:259200
> > .66.77.88.in-addr.arpa:88.77.66.55:a:259200
> >
> > ### PTR and A for LAN locals
> > =www.local:192.168.6.6:86400:LL
> > =mail.local:192.168.7.7:86400:LL
> >
> > ### PTR and A for Public
> > =www.domain.com:88.77.66.56:86400
> > =mail.domain.com:88.77.66.57:86400
> >
> >
> > (BTW - easier to configure than bind, eh? Not sure which Ramin
> > recommends.)
> >
> > // George
> >
> > On Wed, Jun 12, 2002 at 11:34:41AM -0400, George Georgalis wrote:
> > >The request gets the the public interface, then (presumably, depends on
> > >your rules) goes to the LAN server and is answered to the client IP,
> > >which is listening for the response from the public IP, no go.
> > >
> > >The LAN server needs to be be on a different subnet, so all traffic is
> > >routed through the router.
> > >
> > >You could remove the host route to the LAN, leaving only the route to
> > >the firewall, then you'll have the same problem if you access the LAN
> > >host via private IP.
> > >
> > >(Corrections welcome ;-)
> > >
> > >// George
> > >
> > >On Wed, Jun 12, 2002 at 10:07:55AM -0500, Glover George wrote:
> > >>Yes I've come across this problem MANY MANY times before, and would
> > >>appreciate it if someone could explain exactly why this doesn't work.
> > >>For instance.  I have 3 machines, a firewall/nat (linux), a linux
> > >>webserver and a windows machine behind it.  Now I am serving a website
> > >>that is on the webserver behind the firewall, and it's dns stuff is
> > >>somewhere out on the internet.  On my windows machine it
> resolves to the
> > >>public interface of the firewall.  Why doesn't packets
> destined for that
> > >>machine realize that they must be sent to the webserver instead of out
> > >>on the public interface? I know it's because the DNAT rule is on the
> > >>prerouting of the external nic, but why doesn't simply putting a DNAT
> > >>rule on the internal work as well?
> > >>
> > >>The only way for me to get this working is to run bind 9 and
> set up two
> > >>different views, to resolve different ip addresses whether
> you're on the
> > >>internet, or in my internal network.  But this is a hack, and
> everytime
> > >>I add someones website, I have to make changes to both views
> on the DNS
> > >>server to get it to work, for every host in that new domain.  It seems
> > >>like there should be an easier way, as I'm sure a LOT of
> people on this
> > >>list come across the same problem before.
> > >>
> > >>May not be possible with the current nat framework, but was just
> > >>wondering if someone could elaborate on it.  As always, thanks in
> > >>advance.
> > >>
> > >>Glover George
> > >>Systems/Networks Administrator
> > >>Gulf Sales & Supply, Inc.
> > >>dime@gulfsales.com
> > >>(228)-762-0268
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: netfilter-admin@lists.samba.org
> > >>[mailto:netfilter-admin@lists.samba.org] On Behalf Of Matthew Hellman
> > >>Sent: Wednesday, June 12, 2002 7:30 AM
> > >>To: Michael Hudin; netfilter@lists.samba.org
> > >>Subject: Re: Internal machines can't resolve external addresses
> > >>
> > >>There is potentially another solution if you don't want to
> run your own
> > >>bind
> > >>server.  Add a third nic to your firewall and put these boxes
> in a DMZ.
> > >>Then you can use PREROUTING/DNAT.
> > >>
> > >>Goodluck,
> > >>Matt
> > >>
> > >>----- Original Message -----
> > >>From: "Michael Hudin" <hudin@zoetrope.com>
> > >>To: <netfilter@lists.samba.org>
> > >>Sent: Tuesday, June 11, 2002 10:00 PM
> > >>Subject: Internal machines can't resolve external addresses
> > >>
> > >>
> > >>Machines in the outside world, can view my websites fine, but
> whenever I
> > >>try
> > >>to go to one of them from a machine on my internal network behind the
> > >>firewall, neither the domain name nor the IP will resolve.  I
> also have
> > >>the
> > >>same problem with my mail server and have to use the internal
> address of
> > >>the
> > >>mail server.  I am going to guess that the best solution to this is to
> > >>run
> > >>some kind of local DNS server on the inside of the firewall which
> > >>resolves
> > >>all my sites internally, but since I don't have a server at
> my disposal
> > >>for
> > >>it, is there some way around this?  I had the POSTROUTING MASQ line on
> > >>and
> > >>that did allow the internal machines to resolve, but it also hid the
> > >>originating address for any outside machine, thus creating a security
> > >>disaster.
> > >>
> > >>-michael
> > >>
> > >>*nat
> > >>:PREROUTING ACCEPT [241:88600]
> > >>:POSTROUTING ACCEPT [0:9862]
> > >>:OUTPUT ACCEPT [68:4275]
> > >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 110 -j
> > >>DNAT --to-destination 192.168.77.2
> > >>-A PREROUTING -d 10.10.10.252 -p tcp -m tcp --dport 25 -j
> > >>DNAT --to-destination 192.168.77.2
> > >>-A PREROUTING -d 10.10.10.251 -p tcp -m tcp --dport 80 -j
> > >>DNAT --to-destination 192.168.77.2
> > >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 80 -j
> > >>DNAT --to-destination 192.168.77.2
> > >>-A PREROUTING -d 10.10.10.250 -p tcp -m tcp --dport 22 -j
> > >>DNAT --to-destination 192.168.77.2
> > >>-A POSTROUTING -o eth0 -j SNAT --to-source 10.10.10.254
> > >>#-A POSTROUTING -o eth1 -j MASQUERADE
> > >>COMMIT
> > >>
> > >>*mangle
> > >>:PREROUTING ACCEPT [18365:3221456]
> > >>:INPUT ACCEPT [10886:760348]
> > >>:FORWARD ACCEPT [7269:2438049]
> > >>:OUTPUT ACCEPT [8009:752540]
> > >>:POSTROUTING ACCEPT [15177:3182145]
> > >>COMMIT
> > >>
> > >>*filter
> > >>:INPUT ACCEPT [0:229546]
> > >>:FORWARD ACCEPT [363:1553786]
> > >>:OUTPUT ACCEPT [2:619341]
> > >>-A INPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> > >>-A INPUT -p tcp -j ACCEPT
> > >>-A INPUT -p esp -j ACCEPT
> > >>-A INPUT -p ah -j ACCEPT
> > >>-A INPUT -i lo -j ACCEPT
> > >>-A FORWARD -i eth1 -j ACCEPT
> > >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 110 -m state --state
> > >>NEW,RELATED,ESTABLISHED -j ACCEPT
> > >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 25 -m state --state
> > >>NEW,RELATED,ESTABLISHED -j ACCEPT
> > >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 80 -m state --state
> > >>NEW,RELATED,ESTABLISHED -j ACCEPT
> > >>-A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport 22 -m state --state
> > >>NEW,RELATED,ESTABLISHED -j ACCEPT
> > >>-A OUTPUT -p udp -m udp --sport 500 --dport 500 -j ACCEPT
> > >>-A OUTPUT -p tcp -j ACCEPT
> > >>-A OUTPUT -p esp -j ACCEPT
> > >>-A OUTPUT -p ah -j ACCEPT
> > >>-A OUTPUT -o lo -j ACCEPT
> > >>COMMIT
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >--
> > >GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
> > >Security Services, Web, Mail,            mailto:george@galis.org
> > >File, Print, DB and DNS Servers.       http://www.galis.org/george
> > >
> >
> > --
> > GEORGE GEORGALIS, System Admin/Architect    cell: 347-451-8229
> > Security Services, Web, Mail,            mailto:george@galis.org
> > File, Print, DB and DNS Servers.       http://www.galis.org/george
> >
> >
> >
> >
>
>
>
>

Internal machines can't resolve external addresses

[Hard__warE]

Yo just answered your own Question ... lol

no Internal MAchines will not be able to go out through your NAT box and
back in

thats just unethical and a big waste of Traffic ...

so do what i do and run a local Bind 9 DNS on your internal

LAN , and set it up so it forwards requests to your ISP's DNS server

or one / many of OpenNICS Servers ... (OpenNIC is a free Domian Name Server
Service )

then setup all your machines to use it as the DNS server for the Internet
(yes even the IPTABLES box if  ya want, even easier just Set up

Bind 9 on your Firewall Box and set bind to only answer to requests on your
Local LAN, and please if your going to do this make sure

you are running Bind9 (DNS Daemon) as a Sercure User/Group that has basiclly
no privliges ei (named)

last but not least you would the have to edit your /etc/reslove.conf on your
Firewall box and set the nameserver to your internal

Ethernet Card IP and for Secondary add  127.0.0.1 (localhost) ..... yay
... :D

you will find this runs great ... If you run into problems feel free to send
me an EMAIL ...  hard__ware@hotmail.com

im on my computer 24/7 (yes with no sleep so please dont piss me off  with
SPAM ... :P )