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

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.

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.