Downstream Can't Ping Upstream

[rlsj]

Here is the system layout. Except for the first, a cat-5 cable connects each item below to the one above:



1. DSL modem, connecting upstream to ISP and Internet. It forwards DSN resolution requests that are directed to 172.30.1.254



2. Gateway router, presently running Slackware, with a DHCP-assigned IP on the upstream NIC and a static IP 192.168.1.1 on the downstream NIC



3. "Large" hub with up to six XP computers downstream



(everything above this point has worked for years)



4. Testbed, Pentium-II running Debian with two NICs. Upstream IP 192.168.1.21, default gateway 192.168.1.1, downstream IP 192.168.2.22



5. "Small" hub



6. Laptop, Windows/XP, IP 192.168.2.9, Gateway 192.168.2.22



Item 4 works fine through the items above it, can access the other computers on the large hub and reach the Internet (I'm using it now with the Epiphany browser).



This is the problem: Item 6 can ping Item 4 at 192.168.2.22 and 192.168.1.21, but it cannot ping anything above that. Pinging 192.168.1.1 returns "Request Timed Out." Trying to connect Item 6 to the Internet ("ping google.com") by first accessing the DNS at 172.30.1.254 reports that the host could not be found, yet Item 4 does it easily.

I'm trying to construct a model of Item 2 in Item 4 so that Debian code can replace the Slackware code presently running in Item 2. Inability to ping from the downstream NIC past the upstream one is a major obstacle.

"route" issued at Item 4 returns
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
localnet * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

I created an /etc/network/options file containing ip_forward=yes. Restarting the network informed me that options were "deprecated." In any case it made no difference.

I changed the gateway known to Item 6. Making it appear as 192.168.1.1 lost the ability to ping 192.168.1.21, otherwise no effect.

Would appreciate any comments. Thanks for your attention!

--Robert Smith, rlsj@ipass.net

[HROAdmin26]

I don't know how involved you are with this setup, but if you're going to be building/maintaining it, you will probably want to follow up with some reading about routers and routing.

You are asking the P-II system to do routing functions, but you have not configured anything on that machine to enable it to do so. On your "production" side, you have a hardware router designed to do what you're trying to make the P-II do.

You have 2 options:
A) Install a routing daemon on the P-II and configure a software router.
B) Use iptables to act as a "many-to-one" router (which is what your gateway router is doing.)

(B) is of course what many people use at home to firewall themselves and enable multiple machines to "share" one IP on their cable/DSL modem.

Yes, you still need to enable IP forwarding (disabled by default.)

Seek the Googles...

[rlsj]

"iptables" -- that's the key word!

I just now copied the iptables command file from Item 2 into Item 4, changing pathnames etc., and guess what -- it works! Item 6 can now reach everything, even with a browser.

It's been seven years since I set up the iptables under Slackware and I'd forgotten they existed. I'll need them when Debian replaces Slackware, so guess it's all right, but It appears to me that masquerading shouldn't be required at Item 4. Shouldn't it be possible to let Item 2 handle the IP masquerading for the whole system -- i.e., let Item 4 pass Item 6's packets intact through to Item 2? What's the key word for that?

Thank you again, HROAdmin26.

--Robert Smith

[rcgreen]

Shouldn't it be possible to let Item 2 handle the IP masquerading for the whole system

No, the computers below item 4 are on a separate subnet. If 4 doesn't
masquerade (or NAT), anyone upstream won't be able to distinguish
individual machines below 4.

[HROAdmin26]

As rcgreen noted, No.

Item 2 and Item 6 are on different network segments. What inter-connects network segments? Routers. If Item 4 is not running a routing daemon or iptables with masquerading, then there are no rules about how/why packets should be moved between the NIC's on Item 4.

[rlsj]

I see an implied rule: one downstream network, maximum, per NIC.

Thank you, gentlemen, for your responses. Now on to transferring Samba and remote login using XDM.

--Robert Smith