SRX

 View Only
last person joined: 18 hours ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  SSH natted connection throught SRX freezed after 1800 seconds

    Posted 01-11-2023 03:32
    Hi,

    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:
    Host *
    ServerAliveInterval 240
    ServerAliveCountMax 2

    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...

    Thanks

    Matteo


  • 2.  RE: SSH natted connection throught SRX freezed after 1800 seconds

    Posted 01-12-2023 09:45
    Hi. 

    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. 



    ------------------------------
    Vidar Stokke
    ------------------------------



  • 3.  RE: SSH natted connection throught SRX freezed after 1800 seconds

    Posted 01-13-2023 09:05
    Edited by sgala 01-13-2023 10:08
    Hi Vidar, I can confirm you that your solution works. (increasing the inactivity-timeout does workaround the issue).

    I found and understood the root cause.

    I'm using a Linux client to connect to other Linux servers. The SRX is in the middle right now.

    Linux have a default tcp keepalive of 7200 seconds
    net.ipv4.tcp_keepalive_time = 7200
    So a process having tcpkeepalive enabled (like ssh) and that open a TCP connection, It sends a tcp keepalive every 7200 seconds. So if the connection is idle, every 7200 seconds the process sends a tcpkeepalive packet over the TCP connection.

    The SRX by default drop the connection if the connection is not used by default at 1200 seconds. So the ssh connection (but this is true for the whole TCP traffic) will be dropped normally by default in this scenario.

    Why a idle SSH connection is not dropped if you use a Linux firewall? I found that the Linux kernel has by default this value:
    net.netfilter.nf_conntrack_tcp_timeout_established = 432000
    So basically a tcp connection that is NATted throught a linux firewall, will be dropped after 432000 seconds, but normally a SSH process send a TCP Keepalive packet every 7200 seconds. That connection will never end in an unexpected way.

    So, if you want to reach a similar behaviour with a SRX platform you have to increase the inactivity-timeout value for all port/services/application where you want to have a "long live" tcp session...

    I tried it increasing the inactivity-timeout to 10800 seconds.
    the connection started with 10800 seconds of timeout
    after 7200 second the timeout counter was reset to 10800 correctly.

    - here the session with 3606 timeout value...
    Session ID: 73014500075, Policy name: ssh-permit/15, State: Stand-alone, Timeout: 3606, Valid
    In: X.X.X.X/50146 --> X.X.X.X/22;tcp, Conn Tag: 0x0, If: ge-0/0/0.70, Pkts: 18, Bytes: 4840,
    Out: X.X.X.X/22--> X.X.X.X/20945;tcp, Conn Tag: 0x0, If: pp0.0, Pkts: 25, Bytes: 4331,
    Total sessions: 2

    - here the session with 10796 timeout value resetted after 7200 seconds, exactly at 3600 seconds  (10800-7200 seconds= 3600)
    Session ID: 73014500075, Policy name: ssh-permit/15, State: Stand-alone, Timeout: 10796, Valid
    In: X.X.X.X/50146 -->X.X.X.X/22;tcp, Conn Tag: 0x0, If: ge-0/0/0.70, Pkts: 18, Bytes: 4840,
    Out: X.X.X.X/22--> X.X.X.X/20945;tcp, Conn Tag: 0x0, If: pp0.0, Pkts: 26, Bytes: 4383,
    Total sessions: 2

    This is really strange and not well documented. Hope that this will be useful to someone in the future.

    Thanks

    Matteo



    ------------------------------
    Matteo Sgalaberni
    ------------------------------