> >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.
Yes, actually, weblet just captures the output of "svi network ipfilter
list" and spits it back as a web-page...
> >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"
You've got me on this one...I don't know why pings are not working. There
are no denies of ICMP packets in your firewall rules listed above. Is the
machine you're trying to ping setup to send back reply packets? Is it
possible you've got ICMP messages blocked on the server you're trying to
ping? I don't see anything in your LRP setup that would keep pings from
working...
> I have added temporary entries to my network.conf to place .172 fully
outside.
> Everything seems to be working fine at the moment.
I think I know why the game-server is breaking inside the firewall. Matthew
masquerades outbound UDP packets by default, which is somewhat more secure
than allowing direct UDP connections between the DMZ and the outside world,
but tends to break any inbound UDP services (note there are exceptions to
the UDP masquerading for BIND, typically the only public UDP based service
run on a DMZ). To fix this for your game server, you'll need to edit
/etc/ipfilter.conf as follows:
Find the following code section in /etc/ipfilter.conf (very near the end,
near the comment # COnnect DMZ to internet:
$IPCH -A forward -j ACCEPT -p icmp -s 0/0 -d $DMZ_NET -i $DMZ_IF
$IPCH -A forward -j ACCEPT -p tcp -s $DMZ_NET -d 0/0 -i $EXTERN_IF
$IPCH -A forward -j ACCEPT -p icmp -s $DMZ_NET -d 0/0 -i $EXTERN_IF
$IPCH -A forward -j ACCEPT -p udp -s $DMZ_NET domain \
-d 0/0 -i $EXTERN_IF
$IPCH -A forward -j MASQ -p udp -s $DMZ_NET -d 0/0 -i $EXTERN_IF
Chage the last line from:
$IPCH -A forward -j MASQ -p udp -s $DMZ_NET -d 0/0 -i $EXTERN_IF
to:
$IPCH -A forward -j ACCEPT -p udp -s $DMZ_NET -d 0/0 -i $EXTERN_IF
This will provide normal (un-masqueraded) UDP connections between the DMZ
and the outside internet. As long as you only allow specific UDP ports
inbound using the DMZ_OPEN_DEST variable, you should be secure (other than
any potential security bugs in the services you're specifically allowing).
You also need to move your game server back behind the LRP box.
Let me know if this fixes the game server when running behind LRP.
Sorry I don't know what to do about your broken pings other than fish for
more data:
Does pinging your servers work from the internet?
Did you try to ping any servers before capturing the firewall rules posted
above?
> >[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 -
Yes, there are several situations where you might want to use the
eth1_ROUTES variable. Say for instance you had two internal networks,
10.1.2.0/24 and 192.168.1.0/24. The LRP box would be directly connected to
one of these networks, but would need to have an explicit route entered into
eth1_ROUTES to inform the LRP machine about the additional internal network
and how to reach it. You don't need to use the <iface>_ROUTES variables for
interfaces that don't have proxy-arp enabled...
Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-user
