I added the LEAF list back in. I've also edited your reply quite a bit to keep the length manageable and (I hope) to focus on the key remaining loose ends.
At 02:48 PM 12/26/01 -0500, Kory Krofft wrote: ... >> 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)? > >Yes that is exactly what happens. When I ping 24.209.72.1 I get no >response. >When I cancel (ctrl-C) it shows 100% packet loss. > >> >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. > >Yes. The only pingable interface on 192.168.1.X that the DMZ can reach >is >192.168.1.254 (eth1 on the router) Your original message said that "both" subnets are having problems pinging the Internet. Here you elaborate only with respect to the DMZ. Do pings from the *private* LAN (192.168.1.0/24) also fail silently (or with some error message)? If so, are those hosts themselves configured correctly (i.e., with 192.168.1.254 as their default gateways)? ... >I fixed it so that 192.168.10.254 is the only default gateway. >How do I tell it that 192.168.1.254 is the route. Syntactically it would >seem that "route add -net 192.168.1 gw 192.168.1.254" would do it but >route replies "invalid argument". Your don't. Because 192.168.1.254 is *not* the route from the PoV of the Red Hat host. For it, the route to 192.168.1.0/24 is 192.168.10.254 . Try "route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.10.254". Note the last change; the gateway IP address has to be on the LAN. But since 192.168.10.254 is already the default gateway, it doesn't need to be identified as a route to a specific other network. >> 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)? > >I have no firewalling on the DMZ itself. Only what the Dachstein >provides. Once again, please let's use clear terminology. Networks don't run firewalls; hosts (including routers) do. A DMZ is a network; yours contains one host, a Red Hat machine. Are you saying you performed the check I suggested and that "ipchains -L -n" returns ONLY default ACCEPT policies for all 3 built-in chains? >> 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. > >OK. Here is where I really have difficulty. I really haven't got a good >handle >on how the ipchains rules work. I am hoping this exercise will teach me >more >about the whole operation. Up till now I was trying to get the routing >itself >to work before I turned on the DMZ stuff. In looking at the config >script I did >see this section: > >############################################################################### ># Internal Interface >############################################################################### ># Comment 3 settings below for no internal network (DMZ only >configuration) >INTERN_IF="eth1" # Internal Interface >INTERN_NET=192.168.1.0/24 # One (or more) Internal network(s) >INTERN_IP=192.168.1.254 # IP number of Internal Interface > # (to allow forwarding to external IP) >MASQ_SWITCH=YES # Masquerade internal network to outside > # world - YES/NO > >Should there be a similar section for eth2? Or do I append the IP for >eth2 to the >IP for eth1 like so: >INTERN_IF="eth1 eth2" >INTERN_NET=192.168.1.0/24 192.168.10.1/24 >INTERN_IP=192.168.1.254 192.168.10.254 Someone who knows more than I do about the DachStein configuration scripts needs to answer this; as I recall, there is a separate section, later in /etc/network.conf, for configuring a DMZ, but my memory may be faulty. And I don't have a running DachStein handy to check. My earlier suggestion was for you to look at the actual ipchains rules that *result* from the default configuration, not to look at the portions of the config scripts that the user commonly edits. If you run on your LEAF router the command "ipchains -L -n", you'll get a readable bt incomplete list of your firewall rules as actually implemented. The command "ipchains -L -n -v" will give a complete listing, but a harder to read one. Read through the rules in sequence (concentrate on the input chain) to find any rules that handle ICMP type 8 (ping) traffic coming from the DMZ's network range, and see what they say. ... >> 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). > >Sorry I really don't need to hide them at least in this forum. It just >seemed >logical to be safe. the IP's are 24.209.72.0 and 24.209.72.1. Assuming 24.209.72.1 is a remote IP address at the ISP end of your external connection, and the address of interface eth0 is in the range 24.209.72.2-6, that configuration is fine. [older stuff and rest of reply 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
