Hi Paul,
Thanks - it's looking like 1800 seconds....
p...@dis2.millbrook1> show security flow session destination-prefix
216.168.xxx.xxx
Session ID: 434890, Policy name: Linux-to-Internet/8, Timeout: 1800
In: 216.168.xx.xxx/37820 --> 216.168.xxx.xxx/9103;tcp, If: vlan.11
Out: 216.168.xxx.xxx/9103 --> 216.168.xx.xxx/37820;tcp, If: ge-6/0/23.0
This output shows it's 1800 seconds left till this particular session
will be aged out. This value decreases in time while no packets are
received along the session. Since 1800 is the default ttl for tcp, most
probably your devices send keepalives and this is session is never aged
out by the firewall except the devices stop transmitting packets.
When troubleshooting such things you must be sure what exactly happens.
Which part of the three stops sending or transmitting packets. And only
than you ask why this happens.
— What does the output of "show security flow session" tell you at the
moment when the session hangs?
— What does the "close reason" field in correspondent traffic log on the
SRX look like?
— Did you check (using sniffer) that SSH client and server send packets
at the time when the SSH session hangs? Do they, really?
— If yes, check whether the packets reach the SRX.
— If the packets do reach the SRX, check (again with sniffer) whether
they are transmitted on the egress interface. Also whether they reach
the destination.
— If you see the packets really reach the SRX and don't leave it through
the egress interface, turn on [edit security flow traceoptions] in order
to trace stateful packet processing and you'll definitely see the reason
why packets are dropped (if they are).
--
BR,
Pavel
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
