Whle I am not troubled by the length of your reply -- complicated problems take a lot of description -- I do wish you had kept the old subject line (indeed, used one at all) -- your not doing so made it a bit hard to find your earlier message. Also, while the quoted command results you sent came through cleanly, your own writing was munged somehow, and perhaps for this reason I find myself not understanding some of what you wrote. 1. Is mr_bumpy a client on your LAN, OR is mr_bunpy the RH router itself? I can't find where you say. Since it cannot ping the Internet, it would be helpful to know if this failure were occurring in the router or in a client. For the moment, I will assume that mr_bumpy is the RH router. 2. Can you ping the ppp0 default gateway (203.57.130.22 in the ifconfig output you sent) or not? Both from the router and from a client. I don't see where you report the results of this test. 3. I am puzzled by this sentence: "The server works as a router excellently when the firewall isn\'t running." As I understand it, your LAN is using private addressing, so has to be Masq'd. Masq'ing is part of the firewall you are running. So how does the RH host manage to route private-address traffic *before* you implement the firewall? Might it be that you have a limited firewall running already, then you add more rules to it? 4. Have you tried pinging a variety of hosts or just the one in your example? In the Ping-of-Death days, some ISP's set up their routers to block some icmp traffic, and it is possible that you are just hitting an oddity. 5. You say "inside LAN can do NOTHING on the net". From your ping example, this appears to be incorrect -- both the Windows client and the RH server can resolve the FQDN emerge.net.au to IP address 203.57.130.34 . How? How is your LAN doing name resolution (what nameservers are entered in the RH host's /etc/resolv.conf and in the equivalent on the Windows host? Is the RH router running BIND?)? 6. You say: "For pings.. the modem lights flash. For www and telnet past the server they don\'t." This is a bit too terse. Is this true when working from either the server OR a LAN client? Does it differ when using FQDNs or IP addresses (that is, might the modem be showing DNS activity)? With these cautions ... 1. Your routing table shows TWO default gateways, in these lines: >0.0.0.0 203.57.130.22 0.0.0.0 UG 0 0 0 ppp0 >0.0.0.0 192.168.100.1 0.0.0.0 UG 1 0 0 eth0 You want to delete the second of these, since the internal interface is only a static route to the LAN. (This routing table *should* work okay, since it is supposed to get traversed in order ... but I wouldn't count on its complete reliability in the face of this error, in any case.) 2. Although your firewall rules are many, they don't actually do all that much to firewall things. Remember that a packet gets acted upon by the *first* rule it matches, not the most specific rule. So, for example, your INPUT chain starts with these 3 rules: >DENY all ---f-- 0.0.0.0/0 0.0.0.0/0 n/a >ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a >DENY all ----l- 203.57.0.0/16 0.0.0.0/0 n/a The first rule blocks fragmented packets; this mihgt introduce problems on a ppp connection. The second rule accepts everything else. So rules 3 and on never get tested. Based on this, the first thing I'd do is try omitting the first rule and see if that fixes your problems. Since rule 3 logs matching packets, you might also look at your logs and see if they tell you anything informative. 3. Similarly, your lengthy OUTPUT chain has this as its first rule: >ACCEPT all ------ 0.0.0.0/0 0.0.0.0/0 n/a Since all packets will match this rule, the later ones don't get tested. This should not be causing the immediate problems, though. 4. Your FORWARD chain is simple and looks just fine: >Chain forward (policy REJECT): >target prot opt source destination ports >MASQ all ------ 192.168.100.0/24 0.0.0.0/0 n/a So ... none of this is quite an answer to your problem. Partly this is the result of my not yet fully understanding your setup, as my early questions reflect. Part is the (surface) complexity of your firewall rulesets. Perhaps another part is an unfortunate limitation of ipchains reporting -- rule lists don't indicate whether they apply only to specific interfaces (which may have caused me to misinterpret some of your rules). Nonetheless, I hope some of these thoughts prove helpful to you in your efforts. Good luck. At 01:36 PM 5/8/00 +0800, you (senectus) wrote [in part]: >Ray Olszewski (and all else) : ><i>First be more specific about what you mean by \"see the internet\".</i>: >The >inside LAN can do NOTHING on the net as no ping no www, etc, BUT still has >telnet \"to the server (nowhere else)\" and can still read off the shared >folders on the server. [details of diagnostic results deleted] ------------------------------------"Never tell me the odds!"--- Ray Olszewski -- Han Solo Palo Alto, CA [EMAIL PROTECTED] ---------------------------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.linux-learn.org/faqs
