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:[EMAIL PROTECTED] 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 -- 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
