[TriLUG] OT: DNS/Routing Curiosity

Ryan Leathers Ryan.Leathers at globalknowledge.com
Tue Jul 27 10:12:41 EDT 2004


NAPT rather than NAT is a possible culprit.  Without the sort of two way
table a true NAT builds connection establishment is the only "glue" left in
NAPT.  Mix in any variable that doesn't stack establishment in your favor
and things will seem broken.  

-----Original Message-----
From: Aaron S. Joyner [mailto:aaron at joyner.ws]
Sent: Monday, July 26, 2004 5:18 PM
To: Triangle Linux Users Group discussion list
Subject: Re: [TriLUG] OT: DNS/Routing Curiosity


Brian Henning wrote:

>Hi List,
>  Been meaning to toss this question out there and see if anyone would
>enlighten me..  Here's the scoop:
>At home, I can, for example, type in http://cheetah.dynip.com on any
>computer inside my home LAN and get my website.  cheetah.dynip.com points
to
>my DSL external IP.  So apparently, packets for that particular connection
>go outbound, then turn around at the nearest external router to find their
>way to my server.
>At work, however, the same trick doesn't seem to work.
>http://strutmasters.net doesn't come back around to our server; it just
>never gets answered.  From outside it works as expected.
>What could be the difference?
>Is that enough info to explain what I want to know?  I'll be happy to go
>into greater detail if necessary.
>
>Cheers,
>~Brian
>----------------
>Brian A. Henning
>Strutmasters.com
>866.597.2397
>----------------
>
>
>  
>
Your understanding of how the routing works isn't quite right - although 
the end result may be a routing or access issue.  Let's consider the 
following setup

Machine A ---> Machine B ---> Internet

Machine A talks to Machine B on it's internal interface (we'll say it 
has an IP of 1.1.1.1), and uses Machine B as it's default gateway.  
Machine B talks out the Internet on yet-another IP address (we'll call 
it 2.2.2.2), and has it's own, different, default gateway.  If you send 
packets from Machine A to 2.2.2.2, Machine B will accept them on the 
1.1.1.1 interface, and terminate them internally on the 2.2.2.2 
interface.  There's no reason that it would send the packets out, and 
get them back again.

So, why wouldn't you be able to talk to the 2.2.2.2 IP address, from 
Machine A?  Possible answers:
1) Firewall configuration disallows talking directly to the external 
interface IP from internal machines, either by accident or on purpose
2) The service you're trying to talk to won't accept connections from 
the inside addresses, on the external IP, for what-ever reason
3) If the machine uses policy-based routing (i.e. if it has two paths to 
the Internet), and it's not configured well, it might exhibit this 
behavior as well.  This one isn't very likely.

That's about all that comes immediately to mind.  Perhaps if you can 
provide some more details about how you have Machine B configured, in 
terms of Apache and iptables and routing, more precise answers can be 
gleaned.

Aaron S. Joyner
-- 
TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ  : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc



More information about the TriLUG mailing list