[ale] iptables issue

[JK]

Jim Popovitch wrote:

> JK wrote:
> 
>>As for your REJECT issues, are you sure the packets
>>aren't being rejected by something earlier in the
>>chain? It's hard to know exactly what is going on
>>without seeing the entire ruleset.
> 
> 
> I can appreciate that, as I'm sure you can appreciate my reasons for not 
> revealing them. ;-)
> 
> Essentially the rules block everything, and only open somethings.  In 
> the case of a webserver, the only rules (other than block everything) 
> are what I described earlier.  The process is trust lo and vpn0, then 
> protect eth0 (tcp finger printing, block multicast/broadcast, refuse 
> where src is same as dst,etc), then allow traffic in/out with certain 
> rules, finally log what remains and then block it.  So, it would appear 
> that this:
>    OUTPUT BLOCKED: IN= OUT=eth1 SRC=WW.XX.YY.ZZ DST=AA.BB.CC.DD LEN=255
>    TOS=0x00 PREC=0x00 TTL=64 ID=52863 DF PROTO=TCP SPT=80 DPT=4091
>    WINDOW=6432 RES=0x00 ACK PSH FIN URGP=0
> is getting blocked because it doesn't meet this:
>    iptables -A OUTPUT -p tcp -s WW.XX.YY.ZZ --sport http
>        -m state --state RELATED,ESTABLISHED -j ACCEPT
> which is strange because the DST is a connecting webbrowser which apache 
> logs show has seen some data, but apparently iptables is blocking a 
> piece.  That is to say that the visitor received many pages/images (www 
> transactions), but iptables blocked one of them or a piece of one of them.

This appears to be a server-side "close connection"
packet (FIN).  It may be that it's a
re-send of a FIN that had been sent previously,
and at the time it was put in the outgoing queue,
the connection was still open. By the time it
got into the filter, though, the client had
replied to the earlier FIN and the connection was
closed.  (This is just a hypothesis; I don't
know whether the kernel's handling of closing
connections would actually admit this behavior.)

-- JK