Bad confusion about what to do with auth.

[Anders Peter Fugmann]

Steven W. Orr wrote:
> I'm sorry. I mispasted the line. Here's a complete line. I don't know how 
> to fully interpret this, but it looks to me like this is an outgoing 
> packet (though I have no idea what process would create it) but I do have 
> auth on the output accept list. I don't understand what the FIAIF_SCAN 
> means and I also don't understand if the packet is actually being blocked 
> or not.
Pakcets classified as SCAN packets are dropped.
> 
> Feb 22 09:38:55 saturn kernel: [FIAIF_SCAN]:IN= OUT=eth0 
>              SRC=207.172.210.41 DST=216.250.231.90
> 	     LEN=40 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=TCP SPT=113 
>              DPT=40415 WINDOW=0 RES=0x00 ACK RST URGP=0
The packet here is a packet originating from the firewall, as an answer 
to a connection request on port 113 (ident daemon). The pakcet should 
never have been dropped, and since it is, I suspect that some servers 
reject your initial connection attempt.

Seems like a bug in the netfilter code. I can reproduce here with linux 
version 2.6.15. What version of Linux are you using?

The tecnical description of the problem is, that the netfilter 
connection tracking code sees the packet as "related" to an existing 
connection. But for related connection ACK,RST (acknowledge SYN, and 
reset the connection), is invalid for any connection attempt (As this 
would happen either for new connections and established connections - 
Not related connections) - I will forward the question to the netfilter 
list for why the connection is regarded as "related" and not "new".

Until I fint the reason (and a fix), comment the line 66 in 
/usr/share/fiaif/sanity_check.sh reading:
"IPTABLES -t ${TABLE} -A ${QUEUE} -p tcp --tcp-flags ALL RST,ACK -m 
state --state RELATED -j LOG_SCAN"

This will revert to expected behaviour.

Thanks for the report.

Anders Fugmann