I have just upgraded to R80 and it seems like my long timeout service is not taking the override into consideration

[Patrick_Gohier]

Hello all,

I just upgraded our management and one of our location to R80.10 from R77.30.

We currently have a service with a very long tcp timeout period (86400 seconds) that does not work anymore after the upgrade.

After looking at the service settings it's still set to 86400 and the connections on port 1521 still timeout after a short time.

In smartlog I get TCP packet out of state drop with flags : PUSH-ACK.

It seems like my gateway is idling out my connections.

thank you for your help

[Vladimir]

Please verify that the service is being identified as the one that you have TCP timeout properties adjusted, as there is more than one service listed on 1521:

[Patrick_Gohier]

Yes. After reviewing all of my services on port tcp 1521 are with a 24h timeout rule.

I only updated the management to R80.10 and everything was working before the upgrade. There was no change to the rule base or the service base.

[Timothy_Hall]

Try running the undocumented command fw ctl conntab which will give a nice concise list of connections including the current value of the idle timer.  Will help ensure idle timers are being set as you expect for the port 1521 connections and that they are not being removed/expired for some other reason.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Patrick_Gohier]

After running your command it seems like my issue is not on the timeout side then. It shows that they all are using the 24h timeout.

I will try and look further and see where the issue lies.

Thanks for the help

[Timothy_Hall]

Another thing to check is that timeouts are handled a bit differently when SecureXL is enabled, but that should not cause the behavior you are seeing.  Try excluding the port 1521 traffic from SecureXL as specified in sk104468: How to disable SecureXL for specific IP addresses and see if it has an impact on the issue. 

Enabling TCP state logging as specified in sk101221: TCP state logging may also help in determining what is happening to those connections.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com