[j-nsp] Default SRX Behaviour

Piotr Bratkowski pioterbrat at o2.pl
Fri Aug 6 07:15:58 EDT 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi,

Maybe you should enable logging on your policy permit rules (
session-close) and see what logs says about reason for closing the
session.

Regards,
Piotr Bratkowski

W dniu 2010-08-06 12:28, Pavel Lunin pisze:
>
> Hi Paul,
>
>> Thanks - it's looking like 1800 seconds....
>>
>> paul at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJMW+7uAAoJEFmGJVrtk3rV9IQIAJqPhyS/e0/l64CaYSA9GaOa
N60893N0AKbD8b0pyNWxcNj97Rz7vbM2UuWywUFp1wCMv+3EuMRTuEphbhfxBxvf
CidX9sK/AeKRajxbJiQNC0+spWTS1TeMxa7V+mU0mXTrSEM/u360Rxfn5tkHbiL1
TT4sqV+QWtaNHTaSkK5FKb89YlvmfZuWUUxqdHBllqeDJxDzKVwdzpyVo7njmAxA
9KM/8AyyDXuCn/2rkRo6YuNsHIIXca6X8L2i6yEL3MwanhxY0etwvwFf23IVC3/m
u3dsAKRxoYvUPa1tpH+XNoGBn+1bTqD3lnWE7fvIpQsz1Kq0cJmn2AP21plB2aA=
=mW7s
-----END PGP SIGNATURE-----



More information about the juniper-nsp mailing list