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

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


2. Add at least One Existing Cluster Login User Account

It has defined in your existing cluster configuration -> System -> login configuration

3. Execute Discover

If your JunOS Space has access to your cluster and account information is correct, you will get a chart to show how many devices discovered.


You also can check discovery status from Jobs -> Job Management menu to get more information regarding your discovery jobs.


4. Verify your Discovered Devices

From Devices -> Device Management, you can check if devices has been discovered and if has been managed.

5. Start to Use Security Director

After both cluster member devices found from Device management place, you can change applications to Security Director.

From Security Director Devices, you will find only one cluster listed.

6. Start to Import Configurations

From actions menu, you can import this cluster's configuration into JunOS Space Security Director.
It will list all policies and let you decide which one you want to import.
In my case, there are three policies:
a. NAT policies
b. Firewall Policies
c. IPS Policies. This IPS Policies is not active for you to choose because IPS signature version is outdated.

7. Choose all you can selected and Importing them.

8. Verify the Policies Imported

9. Install New Signature Database into the cluster

Note: for some reasons, it always took me install twice to get IPS Signature Database installed. First attempt always failed.


10. Assign policies to the device. 

You will have to do this assign for Firewall Policies and NAT policies. No need to do it for IPS Policies.


11. Assign a template IPS policy to your firewall policy

After you created your IPS template, you will have to switch your IPS configuration from advanced to basic in the Firewall Policies -> Modify Policy, then you could choose your template.


12. Import a Virtual Chassis SRX Cluster

If virtual Chassis has been enabled for NSM/Space management through in-bound interface, following two solutions can be used to help you import them into Space.

Solution A: Remove Virtual Chassis flag with command 

delete chassis cluster network-management cluster-master
Commit then reboot

Solution B: use Master only Management IP address

groups {
    node0 {
        system {
            host-name fw-SRX1-1;
            services {
                ssh {
                    max-sessions-per-connection 32;
                }
            }
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 10.2.8.3/24 {
                            master-only;
                        }
                        address 10.2.8.4/24 {
                            preferred;
                        }               
                    }
                }
            }
        }
    }
    node1 {
        system {
            host-name fw-SRX1-2;
            services {
                ssh {
                    max-sessions-per-connection 32;
                }
            }
        }
        interfaces {
            fxp0 {
                unit 0 {
                    family inet {
                        address 10.2.8.3/24 {
                            master-only;
                        }               
                        address 10.2.8.5/24 {
                            preferred;
                        }
                    }
                }
            }
        }
    }
}


Reference:

Junos Space Security Director
[SRX] NSM/Junos Space fails to recognize SRX as a cluster/standalone device type unless Virtual Chassis flag is removed





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: