Junos release 12.1X45-D25

Product Affected:

SRX100, SRX110, SRX210, SRX220, SRX240, SRX550, SRX650, SRX1400, SRX3400, SRX3600, SRX5600, SRX5800, JunosV Firefly (limited availability), J2320, J2350, J4350, J6350, LN1000, LN2600

 
Alert Description:
This bulletin is to notify Juniper Networks customers that JUNOS release 12.1X45-D25 has been released.

Configure Sophos anti-virus on SRX devices

The Sophos AV solution uses the sophos-engine, which is different from the kaspersky-lab-engine and juniper-express-engine. Before configuring the Sophos AV on the device, check if the av_key_sophos_engine license is installed on it; to verify if the license is installed on the device, run the show system license usage command and look for the av_key_sophos_engine license.


Sample output:

root> show system license usage

Feature name	Licenses    used	Licenses installed	Licenses   needed	Expiry
av_key_kaspersky_engine	1	0	1	29 days
anti_spam_key_sbl	1	0	1	29 days
wf_key_surfcontrol_cpa	1	0	1	29 days
ax411-wlan-ap	0	2	0	permanent
av_key_sophos_engine	1	0	1	29 days
logical-system	0	1	0	permanent

If the license is not installed, refer to KB14103 - SRX License Installation steps after registering product for auto license installation. You can also download the license file and add it by using the following command:

root>request system license add terminal

Configuration:

The configuration is similar to that of the other AV engines.

JWeb procedure:

Configure the express antivirus feature profile:

1. Go to Configure > Security > UTM > Global options and click the Anti-Virus tab.


2. In the Engine Type list, select Sophos and click OK.


3. If the policy is successfully saved, you will receive a confirmation; click OK again. If the profile is not successfully saved, you can click Details in the displayed pop-up window to find out the reason.

Configure a UTM policy for express antivirus:

1. Go to Configure > Security > Policy > UTM Policies and click Add to configure a UTM policy; the Add Policy window is displayed.


2. In the Main tab, next to Policy Name, type a unique name for the UTM policy (for example, sophos-utm-policy).


3. Click the Anti-Virus profiles tab.


4. Next to the HTTP profile, select junos-sophos-av-defaults and click OK.


5. If the policy is successfully saved, you will receive a confirmation; click OK again. If the profile is not successfully saved, you can click Details in the displayed pop-up window to find out the reason.

Create a security policy and attach the UTM policy to it:

1. Go to Configure > Security > Policy > FW Policies.


2. From the Security Policy window, click Add to configure a security policy with UTM. The policy configuration window is displayed.


3. In the Policy tab, type a name in the Policy Name text box.


4. In Default Policy Action, select either Deny-All or Permit-All.


5. In From Zone, select a zone from the list and in To Zone, select a zone from the list.


6. Under Zone Direction, click Add a Policy.


7. Select a Source Address.


8. Select a Destination Address.


9. Choose an application by selecting junos-protocol (for all protocols that support antivirus scanning) in the Application Sets list and clicking the right arrow key (—>) button to move it to the Matched box.


10. In Policy Action, select Permit.


11. Click the Application Services tab.


12. In UTM Policy, select the appropriate policy from the list. This action attaches the UTM policy to the security policy.


13. Click OK.


14. If the policy is successfully saved, you will receive a confirmation; click OK again. If the profile is not successfully saved, you can click Details in the displayed window to find out the reason.

CLI procedure:

1. Configuring the type of engine:
   

   set security utm feature-profile anti-virus type sophos-engine

2. Configure the UTM policies for the desired protocols:
   

   set security utm utm-policy sophos-utm-policy anti-virus http-profile junos-sophos-av-defaults
set security utm utm-policy sophos -utm-policy anti-virus ftp upload-profile junos-sophos-av-defaults
set security utm utm-policy sophos -utm-policy anti-virus ftp download-profile junos-sophos-av-defaults
set security utm utm-policy sophos -utm-policy anti-virus smtp-profile junos-sophos-av-defaults

3. Apply this UTM policy in a security policy:
   

   set security policies from-zone trust to-zone untrust policy utm-security-policy match source-address any
set security policies from-zone trust to-zone untrust policy utm-security-policy match destination-address any
set security policies from-zone trust to-zone untrust policy utm-security-policy match application any
set security policies from-zone trust to-zone untrust policy utm-security-policy then permit application-services utm-policy sophos-utm-policy

Troubleshooting:

1. Check the status of the Sophos engine:
   

   root> show security utm anti-virus status

utm anti-virus status:

anti-virus key expire date: 29 days left (grace period)
update server: http://update.juniper-updates.net/sav/
interval: 1440 minutes
pattern update status: next update in 1347 minutes
last result: download version file failed
anti-virus signature version: not loaded
scan engine type: sophos-engine
scan engine information: last action result: No error



2. Check the Sophos AV statistics:
   

   root> show security utm anti-virus statistics

How to configure JSRP on SRX

This Post shown how basic setup of a Chassis Cluster (High Availability).

Configuration

The following are the basic steps required for configuring a Chassis Cluster on SRX210 devices.    

  Physically connect the two devices together to form the control and fabric (data) links. 

Control link: 
On the SRX210 device, connect fe-0/0/7 on device A to fe-0/0/7 on device B.  The fe-0/0/7 interface on device B will change to fe-2/0/7 after clustering is enabled in Step 2.
Note: It is strongly recommended that the interfaces used for the control link are connected directly with a cable (instead of a switch). If a switch must be used, then refer to KB25017.

Fabric (Data) link: 
On the SRX210 device, connect ge-0/0/1 on device A to ge-0/0/1 on device B. The ge-0/0/1 interface on device B will change to ge-2/0/1 after clustering is enabled in Step 2.  
Note:  For the Fabric (Data) link, it is recommended to use a GE port.  If ge-0/0/1 is not available, you can choose another open port on your devices.  The Fabric (Data) link can be any available open port either onboard or gPIM other than fe-0/0/6 and fe-0/0/7.

It is helpful to know that after step 2, the following will interface assignments will occur:

• fe-0/0/6 will become fxp0 and used as for individual management of each of the devices
• fe-0/0/7 will become fxp1 and used as the control link between the two devices   (This is also documented in KB15356.)
• The other interfaces are also renamed on the secondary device. For example, on a SRX 210 device, the ge-0/0/0 interface is renamed to ge-2/0/0 on the secondary node 1. Refer to the complete mapping for each SRX Series device: Node Interfaces on Active SRX Series Chassis Clusters.

  Enable cluster mode and reboot the devices. Note that this is done in operational mode and not with a configure mode command.

     > set chassis cluster cluster-id <0-15> node <0-1> reboot

For example:

On device A:    >set chassis cluster cluster-id 1 node 0 reboot
On device B:    >set chassis cluster cluster-id 1 node 1 reboot

• Cluster id will be the same on both devices, but the node id should be different as one device is node0 the other device is node1.
• This command will need to be done on both devices.
• The range for the cluster-id is 0-15. Setting it to 0 is the equivalent of disabling cluster mode. User has only 1-15 (15 cluster IDs) ids for working cluster, so user can calculate virtual MAC only for these 15 cluster ids. For more information, refer to [KB13689] How is the virtual MAC address derived for reth interfaces on J-Series and SRX?

After the reboot, note how the fe-0/0/6 and fe-0/0/7 interfaces are re-purposed to fxp0 and fxp1 respectively.



NOTE:  The following steps 3 - 8 can all be performed on the primary device (Device A), and they will be automatically copied over to the secondary device (Device B) when a commit is done.


  Configure the device specific configurations such as host names and management IP addresses. This is specific to each device and is the only part of the configuration that is unique to its specific node.  This is done by entering the following commands (all on the primary node):

On device A:
{primary:node0}
# set groups node0 system host-name <name-node0>      -Device A's host name
# set groups node0 interfaces fxp0 unit 0 family inet address <ip address/mask>  -Device A's management IP address on fxp0 interface
# set groups node1 system host-name <name-node1>      -Device B's host name
# set groups node1 interfaces fxp0 unit 0 family inet address <ip address/mask   -Device B's management IP address on fxp0 interface

The 'set apply-groups' command is run so that the individual configs for each node, set by the above commands, are applied only to that node. This command is required.

  Configure the FAB links (data plane links for RTO sync, etc). For this example we will use physical ports ge-0/0/1 from each node.

On device A:
{primary:node0}
-fab0 is node0 (Device A) interface for the data link
# set interfaces fab0 fabric-options member-interfaces ge-0/0/1

-fab1 is node1 (Device B) interface for the data link    
# set interfaces fab1 fabric-options member-interfaces ge-2/0/1    

Note: There are no configuration commands for the Control link connection. Only the SRX5600 and SRX5800 platforms require configuration commands for the Control link (SPC port).



  Configure the Redundancy Group 0 for the Routing Engine failover properties. Also configure Redundancy Group 1 (all the interfaces will be in one Redundancy Group in this example) to define the failover properties for the Reth interfaces.
Note: If you want to use multiple Redundancy Groups for the interfaces, refer to the Security Configuration Guide.

{primary:node0}
# set chassis cluster redundancy-group 0 node 0 priority 100
# set chassis cluster redundancy-group 0 node 1 priority 1
# set chassis cluster redundancy-group 1 node 0 priority 100
# set chassis cluster redundancy-group 1 node 1 priority 1


  Configure interface monitoring.  Monitoring the health of the interfaces is one way to trigger Redundancy group failover.
Note: Interface monitoring is not recommended for redundancy-group 0.

On device A:
{primary:node0}
# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/0 weight 255
# set chassis cluster redundancy-group 1 interface-monitor fe-0/0/2 weight 255
# set chassis cluster redundancy-group 1 interface-monitor ge-2/0/0 weight 255
# set chassis cluster redundancy-group 1 interface-monitor fe-2/0/2 weight 255

  Configure the Redundant Ethernet interfaces (Reth interface) and assign the Redundant interface to a zone. Make sure that you setup your max number of redundant interfaces as follows:

On device A:
{primary:node0}
# set chassis cluster reth-count <max-number>

-for first interface in the group (on Device A)
# set interfaces <node0-interface-name> fastether-options redundant-parent reth0

-for second interface in the group (on Device B)
# set interfaces <node1-interface-name> fastether-options redundant-parent reth0  

-set up redundancy group for interfaces 
# set interfaces reth0 redundant-ether-options redundancy-group <group-number>      

# set interfaces reth0.0 family inet address <ip address/mask>
# set security zones security-zone <zone> interfaces reth0.0


For example:

On device A:
{primary:node0} 
# set chassis cluster reth-count 2

-for first interface in the group (on Device A)
# set interfaces fe-0/0/2 fastether-options redundant-parent reth1  

-for second interface in the group (on Device B)
# set interfaces fe-2/0/2 fastether-options redundant-parent reth1  

-set up redundancy group for interfaces
# set interfaces reth1 redundant-ether-options redundancy-group 1    
# set interfaces reth1 unit 0 family inet address 192.168.1.1/24

-for first interface in the group (on Device A)
# set interfaces ge-0/0/0 gigether-options redundant-parent reth0  

-for second interface in the group (on Device B)
# set interfaces ge-2/0/0 gigether-options redundant-parent reth0  

-set up redundancy group for interfaces
# set interfaces reth0 redundant-ether-options redundancy-group 1
   
# set interfaces reth0 unit 0 family inet address 10.10.10.200/24
# set security zones security-zone untrust interfaces reth0.0
# set security zones security-zone trust interfaces reth1.0


  Commit and changes will be copied over to the Secondary Node, Device B.

On device A:
{primary:node0}
# commit


This will prepare the basic clustering setting for both the devices.