FW dropping ACK, RST/ACK & FIN/ACK packets though packets are from valid sessions

Opened Support Case #00116776

Barry

OK, this is what you have to do to get it to work if you're using DNAT:

PF rule:
source: ANY (Internet should work too)
service: HTTP (or a group with HTTP/HTTPS)
dest: EXTERNAL ADDRESS
DROP (without logging)


If you're not using DNAT, DEST should be the server's IP.

In my case, I need one for each DNAT'd address.

Naturally these rules should be BELOW the ALLOW rules for your http servers.

Barry

Guys, we fought this in January, remember?

https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/p/39504/135172#135172

Cheers - Bob

Hi Bob,
Although both situations have the solution of adding a packetfilter rule, this wasn't really the same problem.

In this case, these are VALID http sessions, but Astaro's tcp connection tracker times out the session before the browser does, and when the browser tries to do another http request, it tries to 'renew' the same tcp connection, but Astaro's connection tracker already forgot about it, so Astaro logdrops the packet.
For me, this was causing Astaro's logs to fill up with over 300,000 entries per day!

Barry

is the Astaro not obeying the http keep alive then?

is the Astaro not obeying the http keep alive then?

I would assume that ANY tcp traffic on the session would renew the expiration timers on Astaro.


I'm guessing the real problem lies somewhere in the values below:

Web Servers (CentOS and Ubuntu):
$  cat /proc/sys/net/ipv4/tcp_keepalive_time   
7200

Astaro 7.306:
# cd /proc/sys/net/ipv4/netfilter
# cat ip_conntrack_tcp_timeout_close
10
# cat ip_conntrack_tcp_timeout_close_wait
60
# cat ip_conntrack_tcp_timeout_established 
432000
# cat ip_conntrack_tcp_timeout_fin_wait 
120
# cat ip_conntrack_tcp_timeout_last_ack 
30
# cat ip_conntrack_tcp_timeout_max_retrans 
300
# cat ip_conntrack_tcp_timeout_syn_recv 
60
# cat ip_conntrack_tcp_timeout_syn_sent 
120
# cat ip_conntrack_tcp_timeout_time_wait 
120

but I'm not sure which of these values would need to be modified, or if I'm barking up the wrong tree; 432000 > 7200.

Barry

just for giggles any reason you aren't using 7.5x?

just for giggles any reason you aren't using 7.5x?

Server's at a Co-Lo and I'd rather be there when I do the up2dates. I'll be doing it in the next few months.

Barry

ah..that's a good reason.  I've really grown to like ILO cards in remote servers in colo's these days...mainly because i am in MD and my preferred colo is in wash state..[:)]

I've recently returned to the ASG fold for my home network.  I had previously tried it a couple of years ago, but the 10-user limit was insufficient.  With the new 50-user limit on the free Home license, I'm giving it another shot.

I've got pretty much everything I want working, but I'm bugged by the number of ACK FIN, ACK RST, ACK PSH, and ACK PSH FIN packets being logged by the Default Drop rule.  I've implemented the suggested drop-nolog rules for my DNAT'ed services, but the majority of these packets appear to be related to closed outbound connections from my uTorrent client, and the pseudo-random port numbers make them impossible to catch with such a rule.

Any further suggestions on how to handle these would be appreciated.  I do like to check my firewall logs occasionally, and all these entries make it hard to see the wood for the trees.

Here's one happening right now as an example: ASG is reporting 

12:51:23 Default DROP 	TCP 	***.xx.xx.xx:54874→xx.***.xx.xx:50244 [ACK FIN] len=40 ttl=47 tos=0x00 srcmac=00:1d:a2:xx:xx:xx dstmac=00:0b[:D]b:xx:xx:xx

and netstat -an on my torrent machine shows that exact connection in FIN_WAIT_1 state.

Thanks,
  Jon.