Screen OS

Hi, All,

I am baffled how this worked while it should not: SSG has a loopback interface IP 10.4.0.10, I am SSHing from remote office with source IP 10.128.141.40,  SSG does NOT have the valid route back to 10.128.141.40, yet SSH is successful. How did this happen?

SSG(M)-> get session src-ip 10.128.141.40
nat used ipv6 addr: allocated 0/maximum 256256
alloc 1751/max 64064, alloc failed 592602, mcast alloc 0, di alloc failed 0
total reserved 0, free sessions in shared pool 62313
Total 1 sessions according filtering criteria.
id 34779/s**,vsys 0,flag 00400040/0080/0021,policy 320002,time 4320, dip 0 module 0
 if 6(nspflag 200be01):10.128.141.40/55143->10.4.0.10/22,6,001819185e47,sess token 3,vlan 0,tun 0,vsd 0,route 0,wsf 0
 if 3(nspflag 2003010):10.128.141.40/55143<-10.4.0.10/22,6,000000000000,sess token 5,vlan 0,tun 0,vsd 0,route 0,wsf 0
Total 1 sessions shown

SSG(M)-> get int | inc 10.4.0.10
loopback.1     10.4.0.10/32                      Trust       N/A               -   U   0

SSG(M)-> get route ip 10.128.141.40
 Dest for 10.128.141.40
--------------------------------------------------------------------------------------
trust-vr       : => 0.0.0.0/0 (id=27) via 63.9.12.129 (vr: trust-vr)
                    Interface ethernet0/0 , metric 1
SSG(M)->

The SSG get's it route back from the session table. This is default behauvior, can suprise you, can't it? Take a look at page 270 from this document: http://www.juniper.net/techpubs/software/screenos/screenos6.3.0/630_ipv4_cli.pdf : you can change the way a revesed lookup is done.

Thanks, that explains what I saw, this is a very nice feature to have, although I think one should always ensure there are explicit and symetric return routes in firewall's routing table, so this feature is less irrelavent in most cases.