The problem isn't that they can't reach the ports as the ports I allowed are
working.. it's the ports that aren't specified should be handled by the
default chain and/or the last chain which is supposed to be LOGGING and
DROPPING but aren't even run.

        #
        # DROP and log everything if logging is enabled..
        #
        if [ "$LOG" ]; then
          $IPTABLES -A INPUT -j LOG --log-level notice --log-prefix INET
--log-tcp-options --log-ip-options
        fi
        $IPTABLES -A INPUT -j DROP

The rules above rarely get activated ie only XX bytes filtered after a port
scan on any host... should be 100,XXXs bytes dropped..

Doh! Just saw the message from Crossfire, if this is true then this will
explain my problem... argh how annoying. I will test it.. many thanks.

thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L


-----Original Message-----
From: David Fitch [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 3 January 2002 10:15 AM
To: George Vieira
Cc: [EMAIL PROTECTED]
Subject: Re: [SLUG] IPTABLES and confusing messages


On Thu, Jan 03, 2002 at 09:23:52AM +1100, George Vieira wrote:
> I've figured out how to SNAT and DNAT thanks to the help from the previous
> post and SLUGGERS who explained it a bit better than the man pages.
> My problem now is that I have rules (as below) which allow incoming ports
> for TCP, any anything else should be dropped or rejected (-P INPUT  DROP).
> My problem is that the remote site receives a "telnet: Unable to connect
to
> remote host: No route to host" instead of just a TimeOut type of message
> when attempting to test a port (ie telnet).

probably no help to you but... I had a similar thing where people couldn't
get to my webserver from outside yet I could from inside and I was allowing
port 80 etc.  Telnet from outside in showed the same messages about no
route to host.  I discovered (or deduced) that it was due to dingo/optus
blocking inbound port 80 (and 25 and maybe others).  Running my webserver
on a different port works fine.  Maybe just something to check - that your
upstream provider isn't blocking or doing strange routing things to you.

Dave.
-- 
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug

Reply via email to