RE: Ping failures
>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...

    Yeah, I've gotcha alright ;)  You have proven your troubleshooting
    methodology is sound.  I had Norton Internet Security running on that
    box --- and after a recent re-install, it apparently dumped my allow
    ICMP settings. It was responsible for blocking the ping replies.  Beat
    me with the duh stick --- sorry for the extra trouble...

CS> Good...one more problem fixed.  It's easy to forget about firewall rules
when they're spread out in multiple places (I've done it more than a few
times myself).

>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).

    I think you are on it here --- this is consistent with the random port
    above 64000 that my testers were seeing. However....see below:

>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

    ^ Did this --- and re-read it for typos, etc.

>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).

    This didn't seem to work.  While the line above was in place, tcp and
icmp
    worked fine (ping and http in and out).  But, UDP services stopped
working
    altogether (time, game server).  The game server looks for its auth
    server at startup, and barfs when it doesn't find it.  When I changed it
    back to the original setting, the game servers started without a hiccup,
    but are back to the original problem of broken inbound UDP for the
    remote console function.

    I believe my DMZ_OPEN_DEST settings are working --- I commented them
    out to verify they work individually.

    I also tried the tips in Rick O's MiniHOWTo on ensuring all arps on all
    are devices are up to date --- including just letting it all "sit" for
    an hour.

    What do you recommend I re-check?

CS> The problems above are almost certianly due to the setup of your
firewall rules.  By not masquerading any outbound UDP traffic, you will
break any UDP protocols that expect to recieve data from the internet not
explicitly listed in DMZ_OPEN_DEST.  Add any specific UDP protocols you're
using to DMZ_OPEN_DEST and see if that fixes things.  If not, please post a
current firewall rules list, and details about which services are broken.

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

Reply via email to