Showing posts with label Juniper. Show all posts
Showing posts with label Juniper. Show all posts

Wednesday, November 15, 2017

Juniper SRX Commnit Error "No rulebase configured for active policy"

I have been dealing with Juniper SRX IDP error many times when NSM was been used. Mostly those errors are caused by corrupted signature DB or not enough storage space on SRX itself. Here is the latest one I encountered.

Symptoms
From Space, if I make a new change on firewall policy and push it to gateway, I will get following errors.


Thursday, October 19, 2017

Juniper SRX DB mode (Debug mode)

During our regular maintenance, after rebooted one SRX345, and found it stuck at db mode, which is debug mode.

After a short and quick analysis, I found Juniper JunOS devices may get stuck in the boot process or fail to boot the OS, in rare cases, after a sudden power loss or ungraceful power shut down. Juniper  routers, switches and firewalls  can experience file system corruption, which prevents the device from recovering to a functional state. It is recommended that customers minimize their log configurations to prevent excessive read/writes to the file system, which reduces the stress on storage media and reduces the potential occurrence of this issue. Moreover, if abrupt power failures are transient for a very short period of time, the availability of an UPS can also prevent the device from experiencing a sudden power loss.

You do not have to worry about damaging hardware in these situations, as the hardware cannot tell the difference between a graceful shutdown and pulling the power cord. The potential for damage is with the file system structure. It is possible for data to be corrupted, when the computer's power is interrupted with the operating system running. The data could be in the nodes, which could result in files being lost or file contents being corrupted.

Although rare, this issue more likely occurs on platforms that use a UNIX/BSD-based operating system, such as Junos, to access the flash-based storage media.

“Although rare, file system damage can occur with an abrupt power off, which may cause problems on the next boot. Use the request system halt or request system reboot command to gracefully shut down or reboot the OS. Once the OS is halted, it is safe to remove power.”  - from O'Reilly Media’s JUNOS Enterprise Switching book.

There are a couple of KB discussing the fix. KB29811 is using a USB to copy a snapshot from healthy device to faulty device. KB20046  suggest to press space to go to u-boot prompt and enter some commands to fix issue.



db> help
    DDB Quick Help  
  -------------------  
Type 'c' to continue, 'reset' or 'panic' to restart. 

print       p           examine     x           search      set         write       
w           delete      d           break       dwatch      watch       dhwatch     
hwatch      step        s           continue    c           until       next        
match       trace       alltrace    where       bt          call        show        
ps          gdb         reset       kill        watchdog    thread      panic       
ddbdumpsys  dumpsys     
db> reset


Friday, September 8, 2017

Juniper Space Security Director Policy Hit Counts Not Updated Automatically


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.

Thursday, March 30, 2017

Juniper Space License Issue on Citrix Xen Environment

Based on Juniper "Junos Space Virtual Appliance Installation and Configuration Guide" , JunOS Space " must deploy the virtual appliance on a VMware ESX, VMWare ESXi or KVM server, which provides a CPU, hard disk, RAM, and a network controller, but requires installation of an operating system and applications to become fully functional."

In my test environment, one JunOS Space has been installed on Citrix Xen environment and it is working fine until we tried to import a license.

The license was generated from Juniper License site and emailed to us in a txt file. It used to work on another machine hosted in Vmware ESX environment. Unfortunately, this time, JunOS Space said no.

The License Information windows says:
License upload failed. Please check the following:
1) License data format
2) License Keys
Juniper Space VE at Citrix Xen Server - License Error



Thursday, March 23, 2017

Add Juniper SRX Cluster into JunOS Space 16.1 Security Director

My old post "Import Existing Juniper SRX Cluster into JunOS Space Security Director" was created based on Space 14.1 and SRX11.x version. Now both have been upgraded. Space NMP and Security Director have been upgrade to 16.1 (Post is here). SRX240H has been upgrade to 12.1D46.55.

Basically, all steps are similar except the web interface is different. What you need to do is to configure your SRX cluster with a master-only ip on both nodes. The configuration should looks like this:

Wednesday, March 22, 2017

Juniper JUNOS Commands (Tips and Tricks)

Juniper Networks has a Day one book for 'JunOS Tips, Techniques, and Templates 2011' in Junos Fundamentals Series. To record some my own tips, I put them together in this post. Let me know if you have some more to share.

1.  Find big size files 

find . -type f -size +10000 -exec ls -lh {} \; 


root@FW% find . -type f -size +10000 -exec ls -lh {} \;
-rw-r--r--  1 930  929   134M Jan  5 17:34 ./cf/packages/junos-11.4R6.6-domestic
-rw-r--r--  1 root  wheel   139M Sep  8  2011 ./cf/var/log/junos-srxsme-11.2R2.4-domestic.tgz
-rw-r-----  1 root  wheel   4.9M Feb 11 17:12 ./cf/var/db/idpd/db/secdb_02.db
-rw-r-----  1 root  wheel   6.7M Feb 11 17:13 ./cf/var/db/idpd/db/secdb_03.db
-rw-r-----  1 root  wheel    64M Feb 11 17:13 ./cf/var/db/idpd/db/secdb_06.db
-rwxr-xr-x  1 admin  20    24M May 23 08:38 ./cf/var/db/idpd/nsm-download/SignatureUpdate.xml
-r-xr-xr-x  1 root  wheel   5.2M Jan  5 17:33 ./jail/html/dynamic-vpn/client/jam/InstallerComponentSRX.exe
-rw-r--r--  1 root  wheel   139M Sep  8  2011 ./jail/var/log/junos-srxsme-11.2R2.4-domestic.tgz
-rw-r-----  1 root  config    14M Feb  8 22:16 ./mfs/var/run/db/schema.db
-rw-r-----  1 root  wheel    10M Feb  8 22:19 ./mfs/var/sdb/log.0000000001
-r--r--r--  1 root  wheel   6.5M Jan  5 13:59 ./usr/lib/dd/libjkernel-dd.so
-r-xr-xr-x  1 root  wheel    13M Jan  5 15:39 ./usr/sbin/authd
-r-xr-xr-x  1 root  wheel   6.0M Jan  5 16:51 ./usr/sbin/chassisd
-r-xr-xr-x  1 root  wheel    27M Jan  5 13:05 ./usr/sbin/flowd_octeon
-r-xr-xr-x  1 root  wheel    34M Jan  5 13:05 ./usr/sbin/flowd_octeon_hm
-r-xr-xr-x  1 root  wheel   5.5M Jan  5 16:51 ./usr/sbin/kmd
-r-xr-xr-x  1 root  wheel    13M Jan  5 16:24 ./usr/sbin/rpd

% find / -size +100000 | xargs ls -lhS
find: /mfs/var/spool/opielocks: Permission denied
-rw-r--r--  1 930   929     142M Aug 28  2014 /cf/packages/junos-12.1X44-D40.2-domestic
-rw-r-----  1 root  wheel    84M Feb 23 21:31 /cf/var/db/idpd/db/secdb_06.db


Tuesday, March 21, 2017

JunOS Space Network Management Platform Basic Configuration including Log Collector

JunOS Space is in my environment and starting to replace NSM. I have played with in testing lab which recorded in my previous posts:
In this post, I will focus on more regarding JunOS Space itself, some basic configuration to get JunOS space into your production environment.

Notes: Recently Space has been upgraded from 14.1 to 16.1 with my post: Juniper JunOS Space Upgrade Procedures from 14.1 to 16.1. The installation and configuration steps for 16.1 is similar as 14.1. This post is updated during configuring JunOS Space 16.1.

Juniper JunOS Space Upgrade Procedures from 14.1 to 16.1

Usually you can easily upgrade an application from the Junos Space user interface. You must download the image file for the new version of the application, navigate to the Applications page (Network Management Platform > Administration > Applications) and select the application that you want to upgrade. From the right-click menu, choose Upgrade Application to upload the image file into Junos Space via HTTP or SCP.

But upgrade JunOS Space to latest version 16.1 is different and it is not a easy task. There are many steps to follow especially the last step to upgrade to 16.1 from 15.2R2. Here is my recent upgrade procedures.

Steps to upgrade JunOS Space 14.1  to the latest version 16.1:

Monday, November 28, 2016

Procedures to Deploy RMA device into Juniper SRX Chassis Cluster

Juniper KB mentioned some RMA steps for failed Juniper device replacement. There are some steps not clear enough. I put some more configuration steps in this post for future reference:

There are many preparation works before you can add RMA device into your chassis group.


Saturday, November 26, 2016

Juniper Firewall SRX240H Crashed with Error 'nearing maxproc limit by uid 0,please see tuning(7) and login.conf(5)'

One of Juniper Firewall SRX240H had a serious crash. Manual reboot/shutdown did not work. To reset it, I would have to do a hard reset / power cycle device.

It would allow to log in from console, but you wont be able to see any configuration.

Here is outputs from this crashed Juniper SRX240H console:


Wednesday, October 26, 2016

Juniper SRX340 HA Configuraiton

The SRX340 Services Gateway has a capacity of 3 gigabits per second (Gbps) and is 1 rack unit (U) tall. This services gateway has eight 1 G Ethernet ports, eight 1 G SFP ports, one management port, 4 GB of DRAM memory, 8 GB of flash memory, and four Mini-Physical Interface Module (Mini-PIM) slots.

SRX 340 Front Panel

SRX 340 Back Panel














The connection is a little different from SRX 240 and 1400. Here are some related posts:

Wednesday, August 10, 2016

JunOS SRX Cluster Upgrade Failed


For SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, command introduced in Junos OS Release 9.6 and support for reboot as a required parameter added in Junos OS Release 11.2R2. For SRX100, SRX210, SRX220, SRX240, and SRX650 devices, command introduced in Junos OS Release 11.2R2. For SRX5400 devices, the command is introduced in Junos OS Release 12.1X46-D20.

Symptoms: 

Symptom 1: "tar: Archive contains obsolescent base-64 headers"

root@fw-1> request system software add no-copy /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz no-validate 
Formatting alternate root (/dev/da0s2a)...
/dev/da0s2a: 627.4MB (1284940 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 156.86MB, 10039 blks, 20096 inodes.
super-block backups (for fsck -b #) at:
 32, 321280, 642528, 963776
Extracting /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz ...
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error exit delayed from previous errors
ERROR: Failed to extract /var/tmp/junos-srxsme-12.1X44-D40.2-domestic.tgz to /altroot/cf/packages/install-tmp/junos-12.1X44-D40.2-domestic

Sunday, January 17, 2016

Juniper SRX Minor Alarm Messages - Autorecovery and Rescue Information

During working on Juniper products, such as SRX, NSM and Space, sometimes, there are minor alarms in the system and it requires some actions to clear those alarms based on different situation.

Symptoms:

Here are some minor alarms I met during working on Juniper products.

1.  Autorecovery has recovered corrupted information

Tuesday, January 12, 2016

JunOS Space - Warning Message for Consolidated Configuration

Junos Space is a comprehensive network management solution that simplifies and automates management of Juniper’s switching, routing, and security devices. To those security administrator who like command line, they will still prefer to use command line to change certain things such as host name, routes, system configuration etc. Juniper call it out-of-band commit since it happens at device itself, not from JunOS Space. Usually the JunOS space will auto-synchronize the JunOS Space configuration database with device configuration.

Tuesday, December 15, 2015

Understanding Juniper SRX TCP Security Check

Juniper SRX is a stateful firewall and allows traffic which matches an existing session. Sessions are created when a TCP SYN packet is received and it is permitted by the security policy. This of course means that the firewall needs to see both directions of a flow (client-server and server-client), otherwise these checks will block legitimate packets.

Following flow chart illustrates packet flow sequences both when SYN flag checking is enabled and when it is disabled.
SYN Flag Checking

By default, security TCP check is enabled on all TCP flow sessions. The Junos operating system (Junos OS) performs the following operations during TCP sessions:

  • Checks for SYN flags in the first packet of a session and rejects any TCP segments with non- SYN flags that attempt to initiate a session.
  • Validates the TCP sequence numbers during stateful inspection.

Reset packet is turned off for non-SYN session TCP packets:
{primary:node0}
root@fw-mgmt-trn1-1> show security zones
node0:
--------------------------------------------------------------------------

Security zone: MGMT1
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth4.201

Security zone: TSMGMT
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth4.198

Security zone: MGMT2
  Send reset for non-SYN session TCP packets: Off
  Policy configurable: Yes
  Interfaces bound: 1
  Interfaces:
    reth3.0
We can enable reset packets when received non-syn tcp session packets.
{primary:node0}[edit]
root@fw-mgmt-1# set security zones security-zone MGMT1 tcp-rst

{primary:node0}[edit]
root@fw-mgmt-1# set security zones security-zone TSMGMT tcp-rst

{primary:node0}[edit]
root@fw-mgmt-1# set security zones security-zone MGMT tcp-rst        

Check the settings again:
root@fw-mgmt-1> show security zones 
node0:
--------------------------------------------------------------------------

Security zone: MGMT1
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:
    reth4.201

Security zone: TSMGMT
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:
    reth4.198

Security zone: MGMT2
  Send reset for non-SYN session TCP packets: On
  Policy configurable: Yes  
  Interfaces bound: 1
  Interfaces:reth3.0


Junos OS provides a mechanism for disabling security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations. During no-SYN-check the Junos OS does not look for the TCP SYN packet for session creation. No-sequence check disables TCP sequence checking validation. Also, increases throughput. SYN check and sequence check are enabled by default. The set security flow command disables TCP SYN checks and TCP sequence checks on all TCP sessions thus reduces security. This may be required in scenarios with customers like big transfer files, or with applications that do not correctly work with standards.

Another reason to disable syn-check and sequence-check is the asymmetric flows in your environment. It is best, whenever possible, to ensure that asymmetric flows do not occur; but this is not always possible. So, you can disable these checks globally on the SRX device.

To disable TCP packet security checks:
set security flow tcp-session no-syn-check
set security flow tcp-session no-sequence-check

After you disabled the tcp options, tcp-syn-check, and tcp-sequence-check that are configured at global level, you might want to configure TCP packet security checks at the policy level.

Note: Disabling the global SYN check and enforcing the SYN check after policy search will greatly impact the number of packets that the router can process. This in turn will result in intense CPU operations.

Configure the checking for the TCP SYN bit before creating a session:
[edit]
user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options syn-check-required

Configure the checking for sequence numbers in TCP segments during stateful inspection:
[edit]
user@host# set security policies from-zone Zone-A to-zone Zone-B policy pol1 then permit tcp-options sequence-check-required

It is also possible to disable TCP SYN or sequence checking on one policy and enable them on all other policies, an apply-group can be used to complete this configuration based on KB24566.


Reference:



Thursday, December 10, 2015

Juniper SRX Logging Methods and Configuration: Stream Mode vs Event Mode

JunOS has strong flexibility on many features. One of them is logging. It support flexible logging options. This post summarizes some concepts I learned from my work and studying.

1.Understand Juniper SRX logging Type:

1.1 System Logging

Junos OS supports configuring and monitoring of system log messages (also called syslog messages). You can configure files to log system messages and also assign attributes, such as severity levels, to messages. Reboot requests are recorded to the system log files, which you can view with the show log command. SRX Series devices can send system log messages from the control plane (Routing Engine) to one or more destinations. Destinations can include local files on the SRX Series device (because the SRX Series device is a syslog server), remote syslog servers, user terminals, and the system console.


admin@fw-1> show configuration system syslog
archive size 750k files 2;
user * {
    any emergency;
}
host 10.9.0.33 {
    any any;
    change-log none;
    interactive-commands none;
    explicit-priority;
}
host 10.9.8.52 {
    any any;
    source-address 10.9.8.20;
}
file messages {
    any critical;
    authorization info;
    explicit-priority;
}
file interactive-commands {
    interactive-commands error;
}
}


Sunday, September 20, 2015

SRX Load Rescue Configuration After Reboot

It did not happen often, but when it happened, you will need to know how to fix it.


The rescue configuration is a previously committed, valid configuration. You must have previously set the rescue configuration through the J-Web interface or the CLI.

test@fw-srx-2> request system configuration rescue save 

test@fw-srx-2> show system configuration rescue 



During today's work, one of SRX firewalls got a problem to load regular configuration file, and it loaded rescue configuration. Here is what the console output told me:



*** FINAL System shutdown message from admin@fw-srx-2 ***           

System going down IMMEDIATELY                                                  

                                                                          


{secondary:node1}

john@fw-srx-2> Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `vnlru_mem' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...0 0 0 done

syncing disks... All buffers synced.

Uptime: 32m35s
Rebooting...
cpu_reset: Stopping other CPUs


U-Boot 1.1.6-JNPR-1.7 (Build time: May  4 2010 - 06:59:58)


SRX_240_HIGHMEM board revision major:1, minor:50, serial #: AAEK3334

OCTEON CN5230R-SCP pass 2.0, Core clock: 600 MHz, DDR clock: 333 MHz (666 Mhz data rate)
DRAM:  1024 MB
Starting Memory POST... 
Checking datalines... OK
Checking address lines... OK
Checking 512K memory for U-Boot... OK.
Running U-Boot CRC Test... OK.
Flash:  4 MB
USB:   scanning bus for devices... 
Root Hub 0: 3 USB Device(s) found
Root Hub 1: 1 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
Clearing DRAM........ done
BIST check passed.
1:00:00.0 Vendor/Device ID = 0x811210b5
1:01:07.0 Vendor/Device ID = 0xc72414e4
Boot Media: nand-flash usb 
Net:   octeth0
POST Passed
Press SPACE to abort autoboot in 1 seconds
ELF file is 32 bit
Loading .text @ 0x8f000078 (246092 bytes)
Loading .rodata @ 0x8f03c1c4 (13940 bytes)
Loading .rodata.str1.4 @ 0x8f03f838 (16580 bytes)
Loading set_Xcommand_set @ 0x8f0438fc (104 bytes)
Loading .rodata.cst4 @ 0x8f043964 (20 bytes)
Loading .data @ 0x8f044000 (5620 bytes)
Loading .data.rel.ro @ 0x8f0455f4 (120 bytes)
Loading .data.rel @ 0x8f04566c (136 bytes)
Clearing .bss @ 0x8f0456f8 (11912 bytes)
## Starting application at 0x8f000078 ...
Consoles: U-Boot console  
Found compatible API, ver. 1.7

FreeBSD/MIPS U-Boot bootstrap loader, Revision 1.7

(builder@shoth.juniper.net, Tue May  4 07:15:51 UTC 2010)
Memory: 1024MB
[0]Booting from nand-flash slice 1
Un-Protected 1 sectors
writing to flash...
Protected 1 sectors
Loading /boot/defaults/loader.conf 
/kernel data=0xb0567c+0x134494 syms=[0x4+0x8aa50+0x4+0xc8fc6]


Hit [Enter] to boot immediately, or space bar for command prompt.

Booting [/kernel]...               
Kernel entry at 0x801000e0 ...
init regular console
Primary ICache: Sets 64 Size 128 Asso 4
Primary DCache: Sets 1 Size 128 Asso 64
Secondary DCache: Sets 512 Size 128 Asso 8
GDB: debug ports: uart
GDB: current port: uart
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
kld_map_v: 0x8ff80000, kld_map_p: 0x0
Copyright (c) 1996-2014, Juniper Networks, Inc.
All rights reserved.
Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
JUNOS 12.1X44-D40.2 #0: 2014-08-28 12:20:14 UTC
    builder@alaranth.juniper.net:/volume/build/junos/12.1/service/12.1X44-D40.2/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel
JUNOS 12.1X44-D40.2 #0: 2014-08-28 12:20:14 UTC
    builder@alaranth.juniper.net:/volume/build/junos/12.1/service/12.1X44-D40.2/obj-octeon/junos/bsd/kernels/JSRXNLE/kernel
real memory  = 1073741824 (1024MB)
avail memory = 526438400 (502MB)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
Security policy loaded: JUNOS MAC/pcap (mac_pcap)
Security policy loaded: JUNOS MAC/runasnonroot (mac_runasnonroot)
netisr_init: !debug_mpsafenet, forcing maxthreads from 4 to 1
cpu0 on motherboard
: CAVIUM's OCTEON 52XX CPU Rev. 0.8 with no FPU implemented
        L1 Cache: I size 32kb(128 line), D size 8kb(128 line), sixty four way.
        L2 Cache: Size 512kb, 8 way
obio0 on motherboard
uart0: <Octeon-16550 channel 0> on obio0
uart0: console (9600,n,8,1)
twsi0 on obio0
dwc0: <Synopsis DWC OTG Controller Driver> on obio0
usb0: <USB Bus for DWC OTG Controller> on dwc0
usb0: USB revision 2.0
uhub0: vendor 0x0000 DWC OTG root hub, class 9/0, rev 2.00/1.00, addr 1
uhub0: 1 port with 1 removable, self powered
uhub1: vendor 0x0409 product 0x005a, class 9/0, rev 2.00/1.00, addr 2
uhub1: single transaction translator
uhub1: 3 ports with 2 removable, self powered
umass0: STMicroelectronics ST72682  High Speed Mode, rev 2.00/2.10, addr 3
dwc1: <Synopsis DWC OTG Controller Driver> on obio0
usb1: <USB Bus for DWC OTG Controller> on dwc1
usb1: USB revision 2.0
uhub2: vendor 0x0000 DWC OTG root hub, class 9/0, rev 2.00/1.00, addr 1
uhub2: 1 port with 1 removable, self powered
cpld0 on obio0
pcib1: <Cavium on-chip PCIe HOST bridge> on obio0
Disabling Octeon big bar support
PCIe: Waiting for port 0 to finish reset
PCIe: Port 0 link active, 2 lanes
PCIe: Waiting for port 1 to finish reset
PCIe: Port 1 link active, 1 lanes
pcib1: Initialized controller
pci0: <PCI bus> on pcib1
pcib2: <PCI-PCI bridge> irq 0 at device 0.0 on pci0
pci1: <PCI bus> on pcib2
pci1: <serial bus, USB> at device 2.0 (no driver attached)
pci1: <network> at device 7.0 (no driver attached)
pcib0: <Cavium on-chip PCIe HOST bridge> on obio0
pci2: <PCI bus> on pcib0
pci2: <processor> at device 0.0 (no driver attached)
gblmem0 on obio0
octpkt0: <Octeon RGMII> on obio0
cfi0: <AMD/Fujitsu - 4MB> on obio0
Timecounter "mips" frequency 600000000 Hz quality 0
###PCB Group initialized for udppcbgroup
###PCB Group initialized for tcppcbgroup
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <ST ST72682 2.10> Removable Direct Access SCSI-2 device 
da0: 40.000MB/s transfers
da0: 1000MB (2048000 512 byte sectors: 64H 32S/T 1000C)
Trying to mount root from ufs:/dev/da0s1a
Attaching /cf/packages/junos via /dev/mdctl...
Mounted junos package on /dev/md0...

Media check on da0

Zone 04 Block 0499 Addr 11f300 : Bad read
Recovering Block
Automatic reboot in progress...
** /dev/da0s1a
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
250 files, 75946 used, 73580 free (28 frags, 9194 blocks, 0.0% fragmentation)
Verified junos signed by PackageProduction_12_1_0
Verified jboot signed by PackageProduction_12_1_0
Verified junos-12.1X44-D40.2-domestic signed by PackageProduction_12_1_0
Checking integrity of BSD labels:
  s1: Passed
  s2: Passed
  s3: Passed
  s4: Passed
** /dev/bo0s3e
** Last Mounted on /config
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
28 files, 52 used, 12386 free (10 frags, 1547 blocks, 0.1% fragmentation)
** /dev/bo0s3f
** Last Mounted on /cf/var
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
616 files, 98342 used, 76976 free (544 frags, 9554 blocks, 0.3% fragmentation)
Checking integrity of licenses:
  JUNOS137657.lic: Passed
  JUNOS187398.lic: Passed
  JUNOS187665.lic: Passed
  JUNOS628672.lic: Passed
Checking integrity of configuration:
  rescue.conf.gz: Passed
Loading configuration ...
mgd: error: Cannot open configuration file: /config/juniper.conf
mgd: warning: loading configuration from /config/rescue.conf.gz
Time and ticks drifted too much,             resetting synchronization...
mgd: commit complete
Setting initial options: .
Starting optional daemons:  usbd.
Doing initial network setup:.
Initial interface configuration:
additional daemons: eventd.
Additional routing options:kern.module_path: /boot//kernel;/boot/modules -> /boot/modules;/modules/ifpfe_drv;/modules;
kld netpfe drv: ifpfed_dialer.
Doing additional network setup:.
Starting final network daemons:.
setting ldconfig path: /usr/lib /opt/lib
starting standard daemons: cron.
Initial rc.mips initialization:.
Local package initialization:.
starting local daemons:set cores for group access
.
kern.securelevel: -1 -> 1
Creating JAIL MFS partition...
JAIL MFS partition created
boot.upgrade.uboot="0xBFC00000"
boot.upgrade.loader="0xBFE00000"
Boot media /dev/da0 has dual root support
WARNING: JUNOS versions running on dual partitions are not same
** /dev/da0s2a
** Last Mounted on /mfs/tmp/snap-tmp.1334/mnt.1334
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
250 files, 75914 used, 74124 free (28 frags, 9262 blocks, 0.0% fragmentation)
Sun Sep 20 17:48:34 UTC 2015

fw-srx-2 (ttyu0)


login: 

For somehow, the regular configuration could not be loaded, and system used rescue configuration instead.

Fix is quite simple. Made a little change to configuration and commit it to generate a new configuration. Reboot and this time console showed the regular configuration loaded successfully:



Checking integrity of licenses:

  JUNOS137657.lic: Passed
  JUNOS187398.lic: Passed
  JUNOS187665.lic: Passed
  JUNOS628672.lic: Passed
Checking integrity of configuration:
  rescue.conf.gz: Passed
Loading configuration ...
mgd: commit complete
Setting initial options: .


Thursday, September 17, 2015

Import Existing Juniper SRX Cluster into JunOS Space Security Director

This instruction is made to those new to JunOS Space and Security Director. The whole procedures are easy to understand with those screenshots and real example.

This is also the last one for my whole series of posts regarding JunOS Space

1. Add both cluster member's fxp0.0 (mgmt interface) IP addresses into JunOS Space

Go to Network Management Platform -> Devices -> Discover Targets, click + icon to add IP address int Device Target


Tuesday, September 1, 2015

JunOS Space Radius Authentication with Free Radius Server TekRADIUS

TekRADIUS is a RADIUS server for Windows with built-in DHCP server. TekRADIUS is tested on Microsoft Windows XP, Vista, Windows 7/8/10 and Windows 2003/2008/2012 server. TekRADIUS complies with RFC 2865 and RFC 2866. TekRADIUS also supports TCP (RFC 6613) and TLS (RFC 6614-RadSec) transports. TekRADIUS has two editions; TekRADIUS(First edition; supports Microsoft SQL Server) and TekRADIUS LT (Second edition; supports SQLite). It runs as a Windows Service and comes with a Win32 management interface.  More feature can be checked from their website.

There are some previous usage posts in my blog:


Those configuration have been proven working well with Checkpoint, Juniper and Cisco devices. Recently our Juniper NSM upgraded to Juniper Space platform. There were some challenges to set up TekRADIUS to work with JunOS Space during configuration. Here are all steps I did and so far it works.

1. Download and Install TekRADIUS

You can get installation file from download page. Current version is 4.9.9. You can use LT version which is SQLite version. Installation is quite straightforward, and configuration is simple as well. 

2.TekRADIUS configuration.

TekRADIUS configuration is able to be done from console window. Go through all tab interfaces and put necessary information in. Your Radius server should be able ready in 10 minutes. In my lab configuration, there are some groups defined in TekRADIUS group tab. Admin group is using active directory authentication and it will automatically log into cisco devices enable mode with privilege 15. All admiistrators defined in users tab will be nested in those groups.
Defined Groups

For the users in admin-read group, difference from admin group is not able to log into enable mode automatically. You will have to enter enable password manually from Cisco device. In admin-read group, there are no cisco-avpair attribute in Success-reply packets.

Radius Client Configuration

Radius Server Configuration

Cisco Attribute

3. JunOS Space Configuration

3.1 Authentication Server Configuration


Authentication Server

3.2 Define a Remote Profile 'admin'


Remote Profile - admin

3.3 Configure JunOS Attribute in TekRadius

Basically, returned authorization data in the RADIUS server are stored as vendor-specific attributes (VSAs). Therefore, you need to update the Juniper dictionary file (Vendor Juniper in Dictionary Editor) in the RADIUS server with the Junos Space defined VSA (Juniper-Junosspace-Profiles). Users in the RADIUS server database should be assigned to return this VSAs, the values of which must correspond to the remote profiles created in the Junos Space server.

3.3.1 Create a new VSA under Vendor Juniper 's attributes list
new vsa - Juniper-Junosspace-Profiles
3.3.2 Assign this new VSA attribute into the group admin
New Success-reply Attribute
Assign this attribute with a value 'admin', which is matching the JunOS Space remote profile name we created at step 3.2. This value will be returned to JunOS Space to do authorization once authentication succeed. 

4. Verify

You should be able to log in with your AD account name and AD password.

4.1 from TekRADIUS server

Here is log from TekRadius server.

01/09/2015 8:50:18 PM - Active Directory Authentication commencing for user 'yanjohn'
01/09/2015 8:50:18 PM - Check items control - Start (Group : admin).
01/09/2015 8:50:18 PM - Check items control - Stop (Group : admin).
01/09/2015 8:50:18 PM - Windows authentication successfull for user 'yanjohn'
01/09/2015 8:50:18 PM - Fetching Success-Reply items - Start.
01/09/2015 8:50:18 PM - Fetching Success-Reply items - Stop.
01/09/2015 8:50:18 PM - Generating Reply Packet - Start.
01/09/2015 8:50:18 PM - Generating Reply Packet - Stop.

RadAuth reply to  : 10.94.200.18:59944 - 01/09/2015 8:50:18 PM
Size              : 82
Identifier        : 24
Attributes        : 

Juniper-Junosspace-Profiles = admin
cisco-avpair = shell:priv-lvl=15
Service-Type = 7


4.2 from JunOS Space Audit Logging

Audit Log

Reference:




Wednesday, August 12, 2015

Configure SRX 240 cluster Step by Step

1. Understanding SRX240 Default Configuration



The following default configurations apply to SRX240 factory default settings
                                                                                     

Default configuration for Security Zone, Security Policy and NAT Rule:






2. Cluster Network Diagram in this LAB

If your devices were used before, it is best to reset them into default configuration. Here are some four different ways and commands to do it

a. request services fips zeroize
b. request system zeroize
c. Delete all commands in the configuration mode
root@# delete    
This will delete the entire configuration
Delete everything under this level? [yes,no] (no) no

you will need to set root password to be able to commit the changes
d. load factory-default

3.  Set root password

By default, there is no password for root user.

set system root-authentication plain-text-password

4. Delete some default configurations on Node0

Please keep this in mind, you will need to delete those configuration on both nodes, node0 and node1. 

delete system name-server
delete system services dhcp

delete vlans

delete interfaces vlan

delete interfaces ge-0/0/0 unit 0

delete interfaces ge-0/0/1 unit 0
delete interfaces ge-0/0/2 unit 0
delete interfaces ge-0/0/3 unit 0
delete interfaces ge-0/0/4 unit 0
delete interfaces ge-0/0/5 unit 0
delete interfaces ge-0/0/6 unit 0
delete interfaces ge-0/0/7 unit 0
delete interfaces ge-0/0/8 unit 0
delete interfaces ge-0/0/9 unit 0
delete interfaces ge-0/0/10 unit 0
delete interfaces ge-0/0/11 unit 0
delete interfaces ge-0/0/12 unit 0
delete interfaces ge-0/0/13 unit 0
delete interfaces ge-0/0/14 unit 0
delete interfaces ge-0/0/15 unit 0
delete security

commit


5. Enable Cluster on node 0 and reboot

root>set chassis cluster cluster-id 2 node 0 reboot 

6. Basic configuration based on the topology

set groups node0 system host-name fw-a
set groups node0 interfaces fxp0 unit 0 family inet address 10.9.12.9/24
set groups node0 interfaces fxp0 unit 0 family inet address 10.9.12.8/24 master-only
set groups node1 system host-name fw-b
set groups node1 interfaces fxp0 unit 0 family inet address 10.9.12.10/24
set groups node0 interfaces fxp0 unit 0 family inet address 10.9.12.8/24 master-only
set apply-groups "${node}"
set chassis cluster reth-count 2
set chassis cluster redundancy-group 0 node 0 priority 200
set chassis cluster redundancy-group 0 node 1 priority 100
set chassis cluster redundancy-group 1 node 0 priority 200
set chassis cluster redundancy-group 1 node 1 priority 100
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
set interfaces ge-0/0/3 gigether-options redundant-parent reth0
set interfaces ge-5/0/3 gigether-options redundant-parent reth0
set interfaces ge-0/0/4 gigether-options redundant-parent reth1
set interfaces ge-5/0/4 gigether-options redundant-parent reth1
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth1 redundant-ether-options redundancy-group 1
set security zones security-zone Zone1
set security zones security-zone Zone2
set security zones security-zone Zone1 host-inbound-traffic system-services all
set security zones security-zone Zone2 host-inbound-traffic system-services all
set interfaces reth0 unit 0 family inet address 10.9.132.18/24
set security zones security-zone Zone1 interfaces reth0.0
set interfaces reth1 unit 0 family inet address 10.9.136.18/24
set security zones security-zone Zone2 interfaces reth1.0


set system backup-router destination 10.0.0.0/8 10.9.12.1
set routing-options static route 0.0.0.0/0 next-hop 10.9.12.1

set security policies from-zone Zone1 to-zone Zone2 policy allow_any match source-address any
set security policies from-zone Zone1 to-zone Zone2 policy allow_any match destination-address any
set security policies from-zone Zone1 to-zone Zone2 policy allow_any match application any
set security policies from-zone Zone1 to-zone Zone2 policy allow_any then permit
set security policies from-zone Zone2 to-zone Zone1 policy allow_any match source-address any
set security policies from-zone Zone2 to-zone Zone1 policy allow_any match destination-address any
set security policies from-zone Zone2 to-zone Zone1 policy allow_any match application any
set security policies from-zone Zone2 to-zone Zone1 policy allow_any then permit

7. Enable Cluster on node 1 and reboot

After did cable connections between two clusters on g0/1 and g0/2, we can enable cluster node 1

Before enable cluster on node1, some basic configuration has to be deleted.

delete system name-server
delete system services dhcp

delete vlans
delete interfaces vlan

delete interfaces ge-0/0/0 unit 0
delete interfaces ge-0/0/1 unit 0
delete interfaces ge-0/0/2 unit 0
delete interfaces ge-0/0/3 unit 0
delete interfaces ge-0/0/4 unit 0
delete interfaces ge-0/0/5 unit 0
delete interfaces ge-0/0/6 unit 0
delete interfaces ge-0/0/7 unit 0
delete interfaces ge-0/0/8 unit 0
delete interfaces ge-0/0/9 unit 0
delete interfaces ge-0/0/10 unit 0
delete interfaces ge-0/0/11 unit 0
delete interfaces ge-0/0/12 unit 0
delete interfaces ge-0/0/13 unit 0
delete interfaces ge-0/0/14 unit 0
delete interfaces ge-0/0/15 unit 0
delete security

commit

After commit, enable chassic cluster :

set chassis cluster cluster-id 1 node 1 reboot 

note: If you are using multiple Juniper Cluster in same Ethernet Environment, they have to configure unique cluster-id. Else the mac address will be conflicted on switch interface and firewall will not be able to handle network traffic properly in that zone. In following example, cluster-id is set to 5 to avoid conflicting. The range for the cluster-id is 0-15.

user@host> set chassis cluster cluster-id 5 node 0 reboot
Successfully enabled chassis cluster. Going to reboot now.

{primary:node0}[edit]
user@host> show chassis cluster status
Cluster ID: 5
Node                  Priority          Status    Preempt  Manual failover

Redundancy group: 0 , Failover count: 1
    node0                   100         primary        no       no
    node1                   1           secondary      no       no

Redundancy group: 1 , Failover count: 1
    node0                   0           primary        no       no
    node1                   0           secondary      no       no

Verification:

You can check the cluster status with the following commands.
show chassis cluster status
show chassis cluster interfaces
show chassis cluster statistics
show chassis cluster control-plane statistics
show chassis cluster data-plane statistics
show chassis cluster status redundancy-group 1

Reference:




NetSec Youtube Videos