Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Patrick_Gohier
Participant

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

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

5 Replies
Vladimir
Champion
Champion

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:

0 Kudos
Patrick_Gohier
Participant

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.

0 Kudos
Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Patrick_Gohier
Participant

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

0 Kudos
Timothy_Hall
Champion
Champion

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events