>I think you're getting close...I'll try to help you get everything working
properly.
Much appreciated :)
>I assume your reports of ping failures are accurate, but the cause is not.
Your routing tables are setup properly (assuming your server machines are on
the DMZ and not plugged directly into the cable-modem network).
Don't know if it makes any difference, but the connection is SDSL, with the
Flowpoint 2200 router in dumbdumb bridge mode.
>> What is NOT happening -- I can't access or ping DMZ servers from the
internal network or from the LRP command line on the router itself. I
assume this is caused by eth0 and eth1 not knowing how to get to eth2 ---
but I don't know what might make this happen. Is that accurate?
>I assume your reports of ping failures are accurate, but the cause is not.
Your routing tables are setup properly (assuming your server machines are on
the DMZ and not plugged directly into the cable-modem network).
OK...now it's just the pings that are failing. I can access the server in the DMZ
from the internal network, and outsiders can see it as well.
>I'm going to need more info to figure out what's broken, as your
network.conf and routing tables look OK to me. Please provide your current
firewall rules (svi network ipfilter list), and details regarding:
Current rules output: http://64.81.226.171/viewfw.htm
This is the output provided by weblet --- is this the same output obtained with
<svi ip ipfilter list> ?? It appears to be, and is much easier to access.
>Accessing the DMZ servers from the internal net...what services on which
machines...does accessing the same service & machine work from the internet?
Hmmm....the game server at .173 was magically granted existence on the internet
without further intervention from me. I am thinking this may have had to do with the
arp cache on the ISP's router (my default gw 64.81.226.1) --- is my guess anywhere in
the ballpark? Some functionality is still missing, but I'll get to the UDP filtering
rules later.
I can now see the http server on .173 from my inside machines, so I am assuming
this problem is solved.
>Pinging from the LRP box and from client machines...it looks like you've got
ICMP forwarding enabled for the DMZ, so this *should* be working...please
provide details on exactly what you tried, and the exact error message ping
returned (if any).
From a Windows machine inside: "Request timed out"
From the LRP command line: No output until Cntl-C then
"X packets transmitted, 0 packets received, 100% packet loss"
>This is because your LRP box still thinks these IP's are on eth2. If you
move one of your servers from the DMZ to the 'outside', you'll need to
remove it's IP from eth2_ROUTES, and add it's IP to DMZ_EXT_ADDRS for
everything to work properly.
I have added temporary entries to my network.conf to place .172 fully outside.
Everything seems to be working fine at the moment.
>NOTE: ...this might be handy for testing...
Why, yes....it is :)
>[adding manual route statements] is handled by the <iface>_ROUTES variable in my
>proxy-arp scripts, so you don't need to do any hacking on the scripts...
Would there ever be a case in which XXX_ROUTES would be used for eth1?
I just noticed that there is no ETH1_ROUTES var in my current .conf -
>> An updated network diagram is here http://64.81.226.171/netdiagram2.txt
>> Current network.conf is here: http://64.81.226.171/net.txt
Thanks again!
Dan
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-user
