Resolve Local Domain

[Barry Parr]

Hi
Can someone explain why ,
on my nokia m1122 , I can't goto mydomain.com from inside my lan ,
but on another router It works fine.

Regards
Barry

[Mark Foster]

Post by Barry Parr
Hi
Can someone explain why ,
on my nokia m1122 , I can't goto mydomain.com from inside my lan ,
but on another router It works fine.

So youre on the inside of a NAT interface, trying to talk directly to the
outside of your NAT interface?

It doesn't work.

Its also well documented...

Simply put...

www.mydomain.com resolves to xxx.xxx.xxx.xxx in the DNS.

Because you're NAT'd, internally you hold ip yyy.yyy.yyy.yyy and your
connections to the internet are translated so that you appear to be on ip
xxx.xxx.xxx.xxx to the rest of the world.

When you do a DNS lookup on www.mydomain.com you're getting the answer
xxx.xxx.xxx.xxx. When you try to talk to that IP, your router realises
that its an IP bound to the router (not the webserver).

The pinhole rules are rules that apply to inbound traffic coming from the
external interface - not the internal one. Internally you'd actually need
to be bouncing the connection in-then-out the _same_ interface. Doesn't
work that way.

If you want to test your webserver you'll need to hit up a web proxy of
some sort - try anonymizer.com.
Or use a local DNS resolver which provides your internal IP, not your
external one, when browsing the host involved. (hosts file.)

Mark.

[Bjorn Nilsen]

2 "work arounds" I have used in the past are:

- have an internal dns server which has an entry for www.mydomain.com to the internal IP address
- have a static mapping in your hosts file

Post by Mark Foster
So youre on the inside of a NAT interface, trying to talk directly to the
outside of your NAT interface?
It doesn't work.
Its also well documented...
Simply put...
www.mydomain.com resolves to xxx.xxx.xxx.xxx in the DNS.
Because you're NAT'd, internally you hold ip yyy.yyy.yyy.yyy and your
connections to the internet are translated so that you appear to be on ip
xxx.xxx.xxx.xxx to the rest of the world.
When you do a DNS lookup on www.mydomain.com you're getting the answer
xxx.xxx.xxx.xxx. When you try to talk to that IP, your router realises
that its an IP bound to the router (not the webserver).
The pinhole rules are rules that apply to inbound traffic coming from the
external interface - not the internal one. Internally you'd actually need
to be bouncing the connection in-then-out the _same_ interface. Doesn't
work that way.
If you want to test your webserver you'll need to hit up a web proxy of
some sort - try anonymizer.com.
Or use a local DNS resolver which provides your internal IP, not your
external one, when browsing the host involved. (hosts file.)
Mark.

[Andrew Walters]

My 3Com OfficeConnect router handles it fine. It simply routes internal conxns
going to whatever happens to be its public IP address back to itself and
through the appropriately forwarded port.

(Does this mean it may be breaking an RFC? dunno)

Andrew

On Thu, 07 Jul 2005 13:43, you wrote:
| > Hi
| > Can someone explain why ,
| > on my nokia m1122 , I can't goto mydomain.com from inside my lan ,
| > but on another router It works fine.
|
| So youre on the inside of a NAT interface, trying to talk directly to the
| outside of your NAT interface?
|
| It doesn't work.
|
| Its also well documented...
|
| Simply put...

[Steve Phillips]

Post by Andrew Walters
My 3Com OfficeConnect router handles it fine. It simply routes internal conxns
going to whatever happens to be its public IP address back to itself and
through the appropriately forwarded port.

yup, and it means its broken because that would mean that it is not
reporting the source IP correctly which could cause issues.

think about this.

192.168.1.1 talks to 1.2.3.4 (your public ip), this then translates to
192.168.1.200 (your server) and forwards a request through saying
"192.168.1.1 is talking to 192.168.1.200 on the web port"

so 192.168.1.200 tries to reply to 192.168.1.1 and seeing as it is on the
local subnet, responds directly (shortest path, directly connected links
take precidence) - as a result, 192.168.1.1 who thinks it is talking to
1.2.3.4 gets an answer from 192.168.1.200 and says "bugger off, i'm not
talking to you" and throws the packet away.

For this to work the host 192.168.1.200 would either have to force all
traffic via its default route (assuming this is the NAT device) and ignore
local precidence or the NAT device would have to do source NATting as well
as Destination NAT which would tend to break logs.

Post by Andrew Walters
(Does this mean it may be breaking an RFC? dunno)

Probably, tho that doesnt tend to be the end of the world - it will
probably produce some rather interesting results in certain situations
however and may also be a security problem allowing someone to spoof your
internal network and cause havok.

The "correct" way to do this would be to run an internal DNS server and
use that as your primary for internal hosts, set internal domains to their
corerect internal addresses and then use domain names instead of IP
addresses. (you could probably subnet your internal network as well which
would probably produce a similar result.
--
Steve.

Post by Andrew Walters
Andrew
| > Hi
| > Can someone explain why ,
| > on my nokia m1122 , I can't goto mydomain.com from inside my lan ,
| > but on another router It works fine.
|
| So youre on the inside of a NAT interface, trying to talk directly to the
| outside of your NAT interface?
|
| It doesn't work.
|
| Its also well documented...
|
| Simply put...
--
This message is part of the NZ ADSL mailing list.
see http://unixathome.org/adsl/ for archives, FAQ,
and various documents.
with "unsubscribe adsl" in the body of the message

[Bruce Hoult]

Post by Steve Phillips

Post by Andrew Walters
My 3Com OfficeConnect router handles it fine. It simply routes internal conxns
going to whatever happens to be its public IP address back to itself and
through the appropriately forwarded port.

yup, and it means its broken because that would mean that it is not
reporting the source IP correctly which could cause issues.
think about this.
192.168.1.1 talks to 1.2.3.4 (your public ip), this then translates to
192.168.1.200 (your server) and forwards a request through saying
"192.168.1.1 is talking to 192.168.1.200 on the web port"
so 192.168.1.200 tries to reply to 192.168.1.1 and seeing as it is on
the local subnet, responds directly (shortest path, directly connected
links take precidence) - as a result, 192.168.1.1 who thinks it is
talking to 1.2.3.4 gets an answer from 192.168.1.200 and says "bugger
off, i'm not talking to you" and throws the packet away.
For this to work the host 192.168.1.200 would either have to force all
traffic via its default route (assuming this is the NAT device) and
ignore local precidence or the NAT device would have to do source
NATting as well as Destination NAT which would tend to break logs.

This works with my WRT54GS access point/router.

G5:~ bruce$ ssh bruce.hoult.org
Last login: Mon Jul 11 23:34:06 2005 from g5.local
Linux 2.6.10.
***@k7:~$ logout
Connection to bruce.hoult.org closed.
G5:~ bruce$ ssh bruce.hoult.org
Last login: Mon Jul 11 23:34:30 2005 from 192.168.0.1
Linux 2.6.10.
***@k7:~$ logout


So it thinks the connection comes from 192.168.0.1, which is the
Linksys router.

You'd think that Cisco would get that sort of thing more or less right,
even in their consumer line, wouldn't you?