Responses interleaved below. At 09:56 AM 12/26/01 -0500, Kory Krofft wrote: >Ray, > >We were correct in that when I removed the extra IP from the interface >it solved the initial problems at least partially. I can now ping eth1 >and eth2 on the lrp but not eth0.
You mean that pings from 192.168.10.1 succeed to 192.168.10.254 -AND- to 192.168.1.254, but -NOT- to 24.209.X.X (where you replace the X.X part with the real value)? Once again, HOW does the ping fail (please assume you ALWAYS have to answer this follow-up question, even if I forget to ask it about a particular ping failure)? >In other words both subnets can ping >the others interface on the router but not past it to the rest of the >subnet. This sounds like a different report, not "other words" for the one above. Are you saying that 192.168.10.1 cannot ping 192.168.1.X (where you replace X with a valid value fot that LAN)? Once again, HOW does the ping fail? See below for more. >If the DMZ (192.168.10.1) can see the interface at 192.168.1.254 >(eth1on lrp) shouldn't the router handle the rest of the routing? >As well as out to the internet? Not exactly. First, the DMZ host (192.168.10.1) still needs to know that 192.168.1.254 is its route to network 192.168.1.0/24 . You note below that that host has 2 default entries (and we can see that the invalid one is the first one). This is likely to be at least part of your problem; more on it below. Second, firewall rulesets can interfere with routing. This can happen on either the RH host or the LEAF router, especially where private-range addresses are involved (default firewall setting often DENY such traffic). Are you running any firewalling on the RH host? (Does the result of "ipchains -L -n" show ANYTHING aside from default ACCEPT policies)? As to the LEAF router ... the network you are looking at *is* a DMZ, after all. Firewalls are *supposed* to limit traffic from the DMZ to the private LAN. I don't recall offhand if DachStein blocks DMZ-to-LAN pings by default, but it easily might (and probably should). Check your firewall ruleset on the router to see if it is blocking this traffic. See if a host on the LAN can ping a host on the DMZ; here, direction does (or at least can) matter to the ruleset. Similarly, the firewall ruleset may easily be blocking traffic that originates on the DMZ from accessing the Internet. The "best" settings here are less obvious; DMZ hosts have to be able to originate *some* requests (DNS resolution is the obvious example), but for the most part, to do their job they only need to be able to respond to incoming traffic. Check your ruleset to see what DachStein DENYs or REJECTs in its default settings for a DMZ. >The route command on the DMZ shows: >Kernel IP routing table >Destination Gateway Genmask Flags MSS Window irtt >Iface >192.168.10.0 * 255.255.255.0 U 0 0 0 >eth0 >127.0.0.0 * 255.0.0.0 U 0 0 0 >lo >default * 0.0.0.0 U 0 0 0 >eth0 >default 192.168.10.254 0.0.0.0 UG 0 0 0 >eth0 > >Again netstat -nr on the lrp gives: > ># netstat -nr >Kernel IP routing table >Destination Gateway Genmask Flags MSS Window irtt >Iface >192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 >eth1 >192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 >eth2 >24.209.X.X 0.0.0.0 255.255.248.0 U 0 0 0 >eth0 >0.0.0.0 24.209.x.x 0.0.0.0 UG 0 0 0 >eth0 > >I thought I understood the rout command well enough to clean up the >router tables on the DMZ but I have had a bit of difficulty. I tried to >delete the extra default entry but I am not sure which one needs to be >there. >Should the default gateway be 0.0.0.0 0.0.0.0 or point to the interface >192.168.10.254 with a netmask of 255.255.255.0. All my Win boxes on >subnet 1 >point to 192.168.1.254 255.255.255.0 and work fine. Right. The answer you infer here is the correct one. Since I'm not sure how you got into this bind, I'm uncertain as to how you can get out. I *think* all you do is run "route del default" once or twice (until the routing table has do default gateway when displayed), then do one "route add default gw 192.168.10.254" to restore a valid gateway entry. As to the Internet ... why have you switched to concealing the external IP addresses? You do so in a way that matters, since I don't know if you intend the entries above of 24.209.X.X and 24.209.x.x to refer to the same or different IP addresses. With the netmask you specify, the X and x in the leftmost positions should be the same, but the X and x in the rightmost positions should be different (but "close enough" in value to be on the same 255.255.248.0 network). For forther troubleshooting of the external connection, you need to tell us what it is, how it gets addresses, and how frequently its IP address and gateway values change. [old stuff deleted] -- ------------------------------------"Never tell me the odds!"--- Ray Olszewski -- Han Solo Palo Alto, CA [EMAIL PROTECTED] ---------------------------------------------------------------- _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
