Issue Symptons:

  • Normally, each firewall rule on the SRX auto-updates a snmp counter for hit-count, regardless of whether ‘count’ is configured or not.  Juniper Space Security Director periodically polls these OIDs and updates the hit-count.   
  • In Junper Space 16.1 R1, the issue found is unable to view policy
    hit counts from Juniper Space Security Director, but SRX itself is keep updating. 

Actions Taken:

  • Verify Security Appliance Policy Hits from Command line
root@fw-mgmt-2> show security policies hit-count 
node1:
--------------------------------------------------------------------------

Logical system: root-logical-system
 Index   From zone        To zone           Name           Policy count
 1       Vlan2              Vlan1        Baramondi_Monitor 0            
 2       Vlan2              Vlan1        10             4428         
 3       Vlan2              Vlan1        50             0            
 4       Vlan2              Vlan1        40             11136        
 5       Vlan2              Vlan1        default-logdrop 0            
 6       Vlan2              Vlan1        53             2007         
 7       Vlan2              Vlan1        54             0            
 8       Vlan2              Vlan1        55             0            
 9       Vlan2              MGMT              6              538          
 10      Vlan2              MGMT              23             0            
 11      Vlan2              MGMT              74             2            
 12      Vlan2              MGMT              default-logdrop 81           
 13      Office              Vlan1        default-logdrop 0            
 14      Office              Vlan1        60             447          
 15      Office              Vlan1        Office_Archive    0            
 16      Office              Vlan1        58             0            
 17      Office              Vlan1        Baramondi_Monitor-1 0            
 18      Office              MGMT              Office_Archive-1  0            
 19      Office              MGMT              default-logdrop 0            
 20      Vlan1       Vlan2               Baramondi_Rules 0            
 21      Vlan1       Vlan2               VA             0            
 22      Vlan1       Vlan2               A_Office_2_Vlan2    292          
 23      Vlan1       Vlan2               default-logdrop 1696         
 24      Vlan1       Office               VA-1           0            
 25      Vlan1       Office               Baramondi_Rules-1 0            
 26      Vlan1       Office               Device-Zone-1  0            
 27      Vlan1       Office               4              1299         
 28      Vlan1       Office               default-logdrop 0            
   ........

It is clearly there is hit counts on SRX itself, but they are not being pulled/pushed into Space. Log collecter has beenconfigured and it is receiving logs from this SRX.
Solutions: 

  • Let Juniper Space manually probe latest policy hits
From Firewall Policies page, you can manually 
  • This is a known issue reported in 16.1R1 version and the
    workaround to resolve this issue is the following:
From
Space CLI run the following command:

mysql
-ujboss -pnetscreen sm_db -e “update RuntimePreferencesEntity set
value=’2′ where name=’POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE’;”
 

Space release 16.1R2.7 (381623)

Last login: Fri Sep  8 15:27:35 2017 from 10.9.200.168

Welcome to the Junos Space network settings utility.

Initializing, please wait


Junos Space Settings Menu

1> Change Password
2> Change Network Settings
3> Change Time Options
4> Retrieve Logs
5> Security
6> Expand VM Drive Size
7> (Debug) run shell

A> Apply changes
Q> Quit
R> Redraw Menu

Choice [1-7,AQR]: 7

[sudo] password for admin: 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# 
[root@space-c6186f1b3edb ~]# mysql -ujboss -pnetscreen sm_db -e "update RuntimePreferencesEntity set value='2' where name='POLICY_HIT_COUNT_MAX_SUBJOBS_PER_NODE';"
Warning: Using a password on the command line interface can be insecure.
[root@space-c6186f1b3edb ~]# 




    • RESTART JBOSS:

First, identify which node has the vip
(eth0:0).  Check each node with the following:
# ifconfig
eth0:0
Recommended restart process (only
if JBOSS restart is needed):
1.    
Stop processes on all JBOSS nodes
# service jmp-watchdog stop
#
servicejboss stop
#
service jboss-dc stop
Note: jboss-dc is only active on VIP node, but the command won’t do
any harm
2.    
Confirm if JBOSS has been turned off
# service
jboss status
3.    
Start services on the vip node
# service jmp-watchdog start
Note: watchdog starts other processes
4.    
After you can login, start services on all of the other nodes
# service jmp-watchdog start


[root@space-c6186f1b3edb ~]# service jmp-watchdog stop
[root@space-c6186f1b3edb ~]# service jboss stop
found and stop jboss
[root@space-c6186f1b3edb ~]# service jboss-dc stop
stop domain controller
[root@space-c6186f1b3edb ~]# service jboss status
jboss is stopped
[root@space-c6186f1b3edb ~]# service jmp-watchdog start
jmp-watchdog running
[root@space-c6186f1b3edb ~]# ifconfig eth0:0
eth0:0    Link encap:Ethernet  HWaddr C6:18:6F:1B:3E:DB  
          inet addr:10.9.200.22  Bcast:10.9.200.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:145 

By Jon

Leave a Reply