Gustav Schaffter wrote:
> Did you compare the results by using DENY instead of REJECT?
Yes. With DENY, the remote machine sent connection requests until it
timed out. With REJECT, the remote machine sent the connection
requests, and was told (in some way) that the port was unavailable. It
didn't seem to process this correctly, because it continued to try to
connect.
> ipchains says REJECT to tell the caller that he is not allowed to
> connect, but DENY to indicate that the port "doesn't exist" or is not
> listening.
Where did you see that? According to the man page, REJECT will deny the
connection, and reply with an ICMP message telling the caller that the
packet was dropped. DENY simply denies the connection. The caller
isn't told anything, so the connection has to time out, rather than fail
quickly.
If there is a reason that REJECT does not behave the same as the port
being non-existant, I'd like to know. I don't see the sense of it, and
if the ICMP message that is sent back after a REJECT doesn't do
anything, why would anyone bother??
> If you were already fully aware of that, then please ignore. :-)
Discussion is the only way to enlightenment. :)
MSG
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
