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

are you actually having performance issues?  If not i wouldn't worry about it.

No performance problems per se, but at least in the early stages I want to keep an eye on the logs for any DNAT services I may have forgotten or missed, and having to plough through all these spurious messages makes that all task the more tedious.  Added to which, it bugs me when something just ain't right. [:P]

Hi Jon, 
Take a look at my posts re bittorrent
https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39525

If you've got it set up like that, you shouldn't have any problems.

Barry

Hi Guys

is anyone still facing the same issue?

Hi Guys

is anyone still facing the same issue?

Hi,

We just updated to V7.506 and began noticing a similar problem with dropped packets. It is occurring with several random sites, but the most are to c2resolver.ctmail.com 

Julio

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

I know this is "old" by now..but I got like 25% of the packages dropped is from a respected company from Norway.
I use DNAT to my webserver and automatic PF rule. Now I wonder how that would work with the above.. in other words, does the automatic rules come before or after my own custom ones.. ?

2011:01:06-23:38:42 asg220_silk ulogd[4267]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth2" srcmac="80:71:1f:c1:7:c0" dstmac="0:1a:8c:15:2:fa" srcip="xx.***.***.xx" dstip="xx.***.xx.xx" proto="6" length="40" tos="0x00" prec="0x00" ttl="117" srcport="57470" dstport="80" tcpflags="ACK FIN"

They are processed in order of placement. Rule #1 is processed first, then rule #2, and so on until a match is made. Once a match is found, all further processing ceases. This is the standard with most firewalls. There is currently a bug in 8.100 where there is no longer a way to view the rules in processing (number) order, but from what I've seen, this is purely cosmetic and due to be fixed soon. 
 
If your talking about the hidden rules that don't display in WebAdmin, I believe that those are processed after any visible ones, like the default inbound drop rule (everything not specifically allowed from WAN ---> LAN is dropped).  Maybe someone from Astaro can let us know for certain.
 
One of the top feature requests is to allow the hidden rules to be displayed in WebAdmin.  http://feature.astaro.com/forums/17359-astaro-security-gateway-feature-requests/suggestions/181341-webadmin-display-of-auto-packet-filter-rules?ref=title .  I don't have a clue why Astaro doesn't do this.  It may make things a little more confusing to a network "newbie", but can make troubleshooting so much easier.

Thanks Scott,

I was well aware of the order of rules and how to manipulate both trafic and logs with it..

So its your second answer I was looking for.. my main issue is that I ticked the "automatic pf rule" when i made the DNAT for a webserver.
That would normally have the result of a new PF rule being added and visible auto created for the lazy admin. In my case there simply is no PF that allows HTTP traffic to pass down to the web server.
However the rule must exist since the web works perfectly from the Internet, and with the full nat loop back locally.

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

Great but there is no allow rule, since I apparently can't see the auto created one. See attached screen capture for the DNAT and FULL NAT. There are no visible rules in PF matching that - only the ones I manually created and those are for like LAN -> ANY and some IMAP and SMTP.

Hi, an 'auto packetfilter rule' would have priority BEFORE any other PF rules, and they are hidden.

If you're having trouble, turn off the auto rule and create your own.

However, ACK/FIN packets are often from expired sessions and will show up as dropped anyways. Not necessarily a problem.

Barry

Hi Barry,

That was the answer I was looking for..
I could create my own yes, and while this is just my home setup it is also my test setup that teaches me alot that is going to benefit me in the more critical work setup. At work there might be somebody else than me that some day might apply a DNAT rule with auto, so in what order they are processed "auto vs manual" is really valuable knowledge.

I am not really trying to fix the problem, since I think I know why it is behaving like that - I just dont want my log with hundreds of these drops and therefor wanted to implement the procedure you suggested about a drop AFTER the allow - which is auto.

I believe the timed out session is caused because of the webproxy the "client" uses. I assume it holds its connections both ways longer than the Astaro, and therefor at a new request or after a very long time will either try to resume or finish the connection which is already long gone in the Astaro.

I dont know if that makes sense, but I saw a simular problem some time ago at work where our hosted webhotel in Sweden was really really slow from the inside network. It turned out to be our providers firewall that dropped the connections long before the webhotel or our internal clients did. In this case however it could be solved by our provider adding more memory to their cluster firewall ( stone gate ) so that it were able to handle longer and more connections.