Screen OS

Hi guys,

Following a flow captured from an old NetScreen in my company (for security reasons, I changed the IP addresses):

id 1916387/s1*,vsys 1,flag 00200440/4000/0003/0000,policy 2549,time 1, dip 0 module 0
if 110(nspflag 800005):192.125.175.100/52650->195.233.171.98/33000,6,00000c07acc1,sess token 28,vlan 1156,tun 0,vsd 1,route 320,wsf 0
if 110(nspflag 800004):192.125.175.100/52650<-195.233.171.98/33000,6,000bfcfe1b10,sess token 25,vlan 519,tun 0,vsd 1,route 42,wsf 0

I dont know so well the ScreenOS but from this output I can understand many important information:

1. A source or a destination NAT has not been implemented, because the IPs are the same both in the second and in the third line.

2. In the first line I can find three different ids about the session (1916387), the vsys (1) and the security policy involved (2549).

But what about the interfaces? What are the names about the egress and ingress interfaces? and what else important information can I see from this output?

In JunOS I can see if the flow works or not. For example, in this case the network flow passes the firewall but it doesn't come back (I can understand it reading the return packets number):

Session ID: 160115580, Policy name: VUC000026807071/3480, State: Active, Timeout: 1232, Valid
In: 37.25.152.14/10756 --> 10.132.143.104/22;tcp, If: reth0.965, Pkts: 1935, Bytes: 101328
Out: 10.132.143.104/22 --> 37.25.152.14/10756;tcp, If: reth7.143, Pkts: 0, Bytes: 0

Can I understand it in the "get session" output from the NetScreen too?

Many my dubts have been solved by this documentation:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB24728&cat=NS_5400&actp=LIST

Nevertheless I don't still understand what are the ingress and egress interfaces. The number 110 is not an ID associated to an interfaces. in the "show sys" output there isn't the 110 number.

And what about my last question? Is there a way to understand if the flows in the "get session" output work or not?

Yes, the if number in the session output should match the interface number in get system.

You can see if session is "working" by checking that there are packet counts in both directions.  Typically the "non-working" sessons have counters in one direction only and zeros in the return flow.

Ciao Spuluka!

---------------------

Yes, the if number in the session output should match the interface number in get system.

---------------------

in "get sys" output I can't see the interface number, but I found it in the "get interface agg2" output:

old_netscreen(M)-> get sys | include 110
old_netscreen(M)-> 
old_netscreen(M)-> get interface agg2
Interface aggregate2:
  description aggregate2
  number 110, if_info 7209840, if_index 0
  link up, phy-link up/full-duplex/auto, admin status up
  status change:1, last change:10/08/2019 00:10:10
  Aggregate port has 4 members: ethernet2/5; ethernet2/7; ethernet2/6; ethernet2/8; 
  vsys Root, zone Null, vr untrust-vr, vsd 0
  *ip 0.0.0.0/0   mac 0010.db88.c46e
  pmtu-v4 disabled
  ping disabled, telnet disabled, SSH disabled, SNMP disabled
  web disabled, ident-reset disabled, SSL disabled

  NHRP disabled
  aggregate bandwidth: physical 4000Mbps, configured 4000Mbps
  packet distribution mode: hashing in slot2 chip1
old_netscreen(M)-> 

ok, I found the interface, but what about the loginal interface? I have many logical interfaces associated with the agg2 interface:

old_netscreen(M)-> get interface all | include agg2
agg2           0.0.0.0/0                         Null        0010.db88.c46e    -   U   -   Root 
agg2.481       0.0.0.0/0                         occ-vpn-xf~ 0010.db88.c46e  481   U   -   cz-occ
agg2.481:1     195.233.27.145/29                 occ-vpn-xf~ 0010.dbff.a6e1  481   I   1   cz-occ
agg2.482       0.0.0.0/0                         occ_dmz_in~ 0010.db88.c46e  482   U   -   cz-occ
agg2.482:1     195.233.27.153/29                 occ_dmz_in~ 0010.dbff.a6e1  482   I   1   cz-occ
agg2.483       0.0.0.0/0                         occ_zone1   0010.db88.c46e  483   U   -   cz-occ
agg2.483:1     195.233.24.17/29                  occ_zone1   0010.dbff.a6e1  483   I   1   cz-occ
agg2.484       0.0.0.0/0                         occ_zone2   0010.db88.c46e  484   U   -   cz-occ
agg2.484:1     195.233.27.33/29                  occ_zone2   0010.dbff.a6e1  484   I   1   cz-occ
agg2.485       0.0.0.0/0                         occ_dmz_ex~ 0010.db88.c46e  485   U   -   cz-occ
agg2.485:1     195.233.27.25/29                  occ_dmz_ex~ 0010.dbff.a6e1  485   I   1   cz-occ
agg2.486       0.0.0.0/0                         occ_pprd_t~ 0010.db88.c46e  486   U   -   cz-occ
agg2.486:1     195.233.27.161/29                 occ_pprd_t~ 0010.dbff.a6e1  486   I   1   cz-occ
agg2.515       0.0.0.0/0                         PUB_FEI_SH~ 0010.db88.c46e  515   U   -   shared-env-ext
agg2.515:1     195.233.221.161/29                PUB_FEI_SH~ 0010.dbff.a6e1  515   I   1   shared-env-ext
agg2.516       0.0.0.0/0                         PUB_FEV_SH~ 0010.db88.c46e  516   U   -   shared-env-ext
agg2.516:1     195.233.221.169/29                PUB_FEV_SH~ 0010.dbff.a6e1  516   I   1   shared-env-ext
agg2.517       0.0.0.0/0                         PUB_FEA_SH~ 0010.db88.c46e  517   U   -   shared-env-ext
agg2.517:1     195.233.221.177/29                PUB_FEA_SH~ 0010.dbff.a6e1  517   I   1   shared-env-ext
agg2.518       0.0.0.0/0                         PUB_BED_SH~ 0010.db88.c46e  518   U   -   shared-env-ext
agg2.518:1     195.233.221.185/29                PUB_BED_SH~ 0010.dbff.a6e1  518   I   1   shared-env-ext
agg2.519       0.0.0.0/0                         PUB_FEV_SH~ 0010.db88.c46e  519   U   -   shared-env-ext
agg2.519:1     195.233.221.209/29                PUB_FEV_SH~ 0010.dbff.a6e1  519   I   1   shared-env-ext
agg2.531       0.0.0.0/0                         Untrust     0010.db88.c46e  531   U   -   Root 
agg2.531:1     195.233.27.17/29                  Untrust     0010.dbff.a6e1  531   I   1   Root 
agg2.533       0.0.0.0/0                         ePost-ext   0010.db88.c46e  533   U   -   shared-env-ext
agg2.533:1     195.232.248.81/29                 ePost-ext   0010.dbff.a6e1  533   I   1   shared-env-ext
agg2.535       0.0.0.0/0                         ePost-int   0010.db88.c46e  535   U   -   shared-env-ext
agg2.535:1     195.232.248.89/29                 ePost-int   0010.dbff.a6e1  535   I   1   shared-env-ext
agg2.1156      0.0.0.0/0                         Untrust     0010.db88.c46e 1156   U   -   shared-env-ext
agg2.1156:1    172.17.110.252/29                 Untrust     0010.dbff.a6e1 1156   I   1   shared-env-ext
old_netscreen(M)-> 
old_netscreen(M)->

so, how can I understand from the "get session" output what are the ingress and egress interfaces? my flow enters and exits from the same interface (agg2) but what are the right logical interfaces?

id 1916387/s1*,vsys 1,flag 00200440/4000/0003/0000,policy 2549,time 1, dip 0 module 0
if 110(nspflag 800005):192.125.175.100/52650->195.233.171.98/33000,6,00000c07acc1,sess token 28,vlan 1156,tun 0,vsd 1,route 320,wsf 0
if 110(nspflag 800004):192.125.175.100/52650<-195.233.171.98/33000,6,000bfcfe1b10,sess token 25,vlan 519,tun 0,vsd 1,route 42,wsf 0

I can undersand it from the vlan id in the "get session" output, but is there a simplest way to understand it? what about the "nspflag 800005" information? what is it? maybe it means the right logical interface, or not?

---------------------

You can see if session is "working" by checking that there are packet counts in both directions.  Typically the "non-working" sessons have counters in one direction only and zeros in the return flow.

---------------------

where can I see the counters in "get session" output?

Sorry for the confusion.  I had forgotten that virtual interfaces won't show up in get system so the interface number can only be seen for those in get interface.

And you are correct the traffic counters is available on the srx but not on screenos.

Unfortunaely the nspflag refers to network service processor which is where the flows are processed as flows so this is not tied to specific interfaces but is an overall resource for all flows to share and is related to the maximum session limits per platform.

So the vlan or the source/destination ip addresses are the only clues to narrow down the sub interface information.

the other clue is routing tables.  Sessions are based on the ingress interface and the egress interface which are determined by the routing table.  So if you look up the ip addresses in the flow in the routing table this will return the interface information you are looking for too.

as I thought,  the "get session" output from ScreenOS is not so good than the "show security flow session" output from JunOS. In these days I had to write a script to read the "get session" output and put the main information in a excel file. it works but to have a good result, I have to specify the interface and the vsys names associated with their ids manually.