Re: IPTables rejecting packets that should be let through???
From: Robert Nichols (rnichols42_at_comcast.net)
To: email@example.com Date: Sun, 10 Apr 2005 13:03:04 -0500
David Hoffman wrote:
> This one is really confusing me...
> I am running IPTables to configure my firewall, telling it to ALLOW
> incoming traffic on eth1 from anywhere to port 25. The way the
> firewall is set up, it says to allow connections that are RELATED or
> ESTABLISHED, before going the following rules. One of the following
> rules says to allow connections that are NEW if they are destined for
> port 25.
> At the bottom of my firewall rules, I have an entry that rejects all
> traffic that has failed to pass all other checks. Right before that
> entry, I have an entry that logs the packet that was rejected.
> What I am seeing is traffic that is coming in from a machine as a NEW
> connection, and is being allowed in. During the SMTP transaction (and
> this only happens sometimes - usually when Postfix has rejected the
> connection for failing some sanity check) Postfix might reject a
> connection, and then shortly after, I see a log entry from the
> firewall for a connection from port 25, but it failed to pass the
> previous checks, and so it rejects it.
> My guess is that the state of the packet is not being considered as
> RELATED, ESTABLISHED, or NEW... but from the packet, I'm not sure if
> there is a way to determine which state the packet is in.
> Is there a way to tell the reason for rejection or the state of a
> packet from the log entry that IPTables generates? Here is an example
> of a log entry that I saw. AFTER valid traffic accepted, an SMTP
> session was setup, and postfix rejected the mail with an error code, I
> saw this message in my log:
> Apr 10 06:40:29 master kernel: IN=eth1
> OUT=MAC=00:50:ba:49:d8:aa:00:20:78:db:4f:3f:08:00 SRC=188.8.131.52
> DST=192.168.158.1 LEN=40 TOS=0x00 PREC=0x00 TTL=108 ID=54733 PROTO=TCP
> SPT=3705 DPT=25 WINDOW=0 RES=0x00 RST URGP=0
Once you've eliminated RELATED, ESTABLISHED, and NEW, the only
remaining state is INVALID. I don't know why the connection
state would be considered INVALID, but that packet looks like a
tcp-reset packet (40 bytes, "RST" flag) that was received after
postfix closed, or tried to close, the connection on your machine.
To see what is actually happening in the handshake you need to
run 'ethereal' and look at the packets.
-- Bob Nichols firstname.lastname@example.org -- fedora-list mailing list email@example.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list