I can't explain the behaviour, but I've changed the SSH-timeouts on an SRX myself. There are two ways to do this:1. Add a new application in addition to the default junos-ssh.
Then you actually have to have a rule that matches this new application definition. This means a rule with "match application any" will still have the timeout 1800. This is a bit of a hazzel. But these commands will create a new application "ssh" and set the timeout:
set applications application ssh protocol tcp
set applications application ssh destination-port 22
set applications application ssh inactivity-timeout 86400
Then you can add this to the appropriate firewall policy:
set security policies from-zone trust to-zone untrust policy ssh-permit match source-address any
set security policies from-zone trust to-zone untrust policy ssh-permit match destination-address any
set security policies from-zone trust to-zone untrust policy ssh-permit match application ssh
set security policies from-zone trust to-zone untrust policy ssh-permit then permit
This has to be put before any other "application any" statements to be triggered. 2. Alternate the default junos-ssh application timeout:
I've not tested this myself, but this might be a way to do it.https://rtodto.net/srx-tips-default-application-timeouts-ssh/
Kinda dirty maybe?
Hope this helps.
Sent: 01-11-2023 03:32
Subject: SSH natted connection throught SRX freezed after 1800 seconds
I'm a newbie on SRX platform. I replaced a linux firewall that was NATting my private LAN with a SRX.
Since that, my ssh connections, passing thought SRX firewall and natted, that are left open but not used, frozen after a while.
I found that by default the SRX have a inactive timeout on security flow session of 1800 seconds.
SSH connections normally have a TCPKeepalive enabled and this should refresh the session inactivity timeout but the SRX seems does not honour it.
To workaround it, I added to my .ssh/config:
With that configuration the security flow session timeout is renewed.
Can someone explain me this behaviour? Should be fine to reach the same goal with linux firewall where TCP session have a inactivity timeout more "real"...
Alterntively: I can't find a way to increase globally on the SRX the tcp session inactivity timeout...