[wellylug] Route Tables + Question + I Hope I explain this...

[Chris Hodgetts]

My routing question .... Trying once again! :)

We have domainname.com pointing to ip address 1
We have lists.domainname.com point to ip address 2
Both those IP addresses are on the same router box, and IP address 2
gets forwarded to penny 192.168.0.68 - well port 80 and 25 do anyway by a firewall and NAT.
Any URL requests get munged by Squid and on forwarded to penny as well and returned to the requesting client.

Anyone who trys and connects inside the company to
lists.domainname.com gets the DNS entry as an outside address - ip
address 2, because we dont have a DNS server inside the company that
serves up domainname.com domain names so it will never find the internal ip of the machine....

So what happens is example jenna 192.168.0.15 pings, lists.domainname.com and DNS resolves to 
ip address 2  - packets go outside the company, and back in side the
company by the router / firewall / squid and get forwarded on to penny.
Just like as if they were requesting over the internet.

If the routing table on penny stays standard, IE 
192.168.0.0        *	blah blah blah eth0
default     192.168.0.33 blah blah blah eth0

The packets get stopped by penny her self. by what we can see with tcpdump
If I remove the route 192.168.0.0    * blah blah blah eth0 
and just leave the default route in, then it works both inside and
outside the company.

It's been sujested that Debian may have some anti-spoofing filter or
something either in the kernel or somewhere else that is dis-allowing
the traffic flow...

I have seen in /etc/network/options a spoofing option, to which I have
changed from N to Y or from Y to N.. and restarted the network
interface, to encounter the same problem.

Its very long winded and probabally didnt explain there very well either
:)

On Fri, 2004-06-04 at 19:06, Enkidu wrote:
> On Fri, 04 Jun 2004 11:45:55 +1200, you wrote:
> 
> >Hello, 
> >
> >I hope I explain this correctly -- 
> >
> >OK.....
> >
> >I have a machine, it has a DNS entry for an external IP address that is
> >different from archnetnz.com, for the purpose of this, we will call it,
> >lists.archnetnz.com
> >
> OK, is it *physically* external or internal? What device seperates
> internal from external networks?
> >
> >When you ping lists.archnetnz.com from within the local network it
> >resolves the external IP address - via the default route, which is what
> >we want....  archnetnz.com is not the internal network suffix nor is
> >there an internal DNS server hosting up .archnetnz.com names....
> >
> I just plain don't understand this. When the DNS resolves a Domain
> name to an IP address the route doesn't come into it. When you ping
> you either get a packet back or not. How do you know what route the
> packet takes? Did you use traceroute?
> >
> >The Ping comes back in via that same default router and it sends it off
> >to the machine in question through a static route.
> >
> How do you know what route the packet comes back from?
> >
> >This is the routing table of the machine in question - -and it works.
> >
> >It will connect internally on the network to the external IP address,
> >and obviously from external to the external IP, for what the static
> >route exists for forwarding all packets to lists.archnetnz.com's ip
> >address to it's internal IP address.
> >
> >ONLY IF THE ROUTE TABLE ON THE MACHINE LOOKS LIKE THIS!
> >
> >penny:/etc/network# route
> >Kernel IP routing table
> >Destination  Gateway       Genmask   lags Metric Ref Use Iface
> >default    192.168.0.33    0.0.0.0   UG    0      0   0  eth0
> >
> >But if it looks like this:
> >
> >penny:/etc/network# route
> >Kernel IP routing table
> >Destination  Gateway       Genmask    lags Metric Ref Use Iface
> >192.168.0.0    *         255.255.255.0 U   0      0   0  eth0
> >default    192.168.0.33    0.0.0.0   UG    0      0   0  eth0
> >
> >Which is the standard route when the interface comes up, it does not
> >route the packets correctly from internal to the external IP address.
> >
> What is .33? Is it your router?
> >
> >Now I hope I have explained it correctly, if you need further
> >clarification on anything please let me know, and I will be happy to
> >provide any further info regarding this :)
> >
> >Thanks...
> 
> Cheers,
> 
> Cliff
--