[Firehol-support] Strange problem...

[Costa Tsaousis]

Sim wrote:
> Hello!
>
> Sometimes I have this strange problem in my Firehol:
>
> Dec 14 12:00:53 firewall kernel: [89443.304634] ''IN-www2fw':'IN=ppp0
> OUT= MAC= SRC=213.210.140.239 DST=77.19.33.12 LEN=40 TOS=0x00
> PREC=0x00 TTL=237 ID=65259 PROTO=TCP SPT=11775 DPT=9999 WINDOW=8011
> RES=0x00 RST URGP=0
>
> Where:
>
> - SRC (external IP)
> - DST (my local IP)
> - DPT (my TCP Service running on server and connected to remote client)
>
> This is my firehol.cfg
> ######################################
>
> server_myservice_ports="tcp/9999"
> client_myservice_ports="default"
>
> interface ppp+ www2fw
>
>         policy drop
>
>         server ICMP accept
>         server "ssh" accept
>         server "ftp" accept
>         server "myservice" accept
>
>         client all accept
>
> interface eth1 [..]
>
> ######################################
>
> Another strange log is:
>
> Dec 14 12:06:02 firewall kernel: [89751.639874] ''IN-www2fw':'IN=ppp0
> OUT= MAC= SRC=80.15.15.15 DST=77.19.33.12 LEN=160 TOS=0x00 PREC=0x00
> TTL=50 ID=56371 DF PROTO=TCP SPT=9999 DPT=59529 WINDOW=2896 RES=0x00
> ACK PSH URGP=0
>
> Where
>
> - SRC (external IP)
> - DST (my local IP)
> - SPT (his TCP Service running on remote client connected with my server)
>
> Have you any idea?
>
> Very thanks!
>   
Hi,

In general firehol matches explicitly the NEW connections and through 
'--m state --state RELATED' all the related packets to each connection. 
This is the right way to do it, since this allows the iptables helpers 
to work as expected.

New TCP connections should have the SYN bit set, which is not in the 
examples you gave above. Therefore, the RELATED match of iptables 
decided that these packets are not really related to an open connection.

This is a common case for FIN ACK packets where the iptables connection 
tracker removed the connection from its list when it saw the FIN, so the 
FIN ACK was just dropped.

I guess (and only guess) that in your case there is something similar. 
For some reason the iptables connection tracker has removed the related 
connections from its list before these packets arrived. So the RELATED 
match did not find them, and firehol dropped them.

So my guesses are:

1. The first packet is RST (reset). Maybe the connection already had 
timed, so the RST just didn't find a connection to reset.
2. The second packet is PSH ACK (push ack). Maybe your server had 
already sent a FIN and this PSH ACK arrived while the FIN was on its way 
to find the client. If I am right, you should also have a FIN ACK 
dropped for the same connection.

Although I suggest to google a bit for it for a better explanation, keep 
in mind that I have never encountered a single case where the iptables 
connection tracker did wrong.

Costa