On the Juniper SRX Branch devices there is a Simple Chassis Cluster Upgrade process detailed here.
Downtime = 30 seconds
Juniper Junos & ScreenOS Firewalls.
Junos: SRX series
ScreenOS: Netscreen Firewalls & SSG/ISG Series
On the Juniper SRX Branch devices there is a Simple Chassis Cluster Upgrade process detailed here.
Downtime = 30 seconds
Summary:
Problem or Goal:
Cause:
Solution:
The basic configuration, along with an example, is as follows:
root@# show security ike { traceoptions { file iketrace; flag all; } proposal ike-prop1 { authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm aes-192-cbc; lifetime-seconds 28800; } policy ike-pol2 { mode aggressive; proposals ike-prop1; pre-shared-key ascii-text "$9$m5z6p0IreW9AeWLxwsP5QF9AuO1hyl"; ## SECRET-DATA } gateway remote-vpn1 { ike-policy ike-pol2; dynamic { user-at-hostname "user1@juniper.net"; connections-limit 2; ike-user-type shared-ike-id; } external-interface ge-0/0/1; xauth access-profile xauth-prof1; } } ipsec { traceoptions { flag all; } proposal ipsec-prop1 { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm aes-128-cbc; } policy ipsec1-lab { perfect-forward-secrecy { keys group2; } proposals ipsec-prop1; } vpn remote-vpn1 { ike { gateway remote-vpn1; ipsec-policy ipsec1-lab; } } } policies { from-zone trust to-zone untrust { policy p1 { match { source-address any; destination-address any; application any; } then { permit { tunnel { ipsec-vpn remote-vpn1; } } } } } } zones { security-zone untrust { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } } } security-zone trust { interfaces { ge-0/0/0.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } } } } root@# show access profile xauth-prof1 { authentication-order password; client michael { firewall-user { password "$9$wtYoGPfz6/tGDi.P56/EcylWL7-VY4a"; ## SECRET-DATA } } client test { firewall-user { password "$9$Cp8gpOIylMNdsEcds24DjCtuOEcrevL7-"; ## SECRET-DATA } } address-assignment { pool xauth-pool; } } address-assignment { pool xauth-pool { family inet { network 10.1.1.0/24; xauth-attributes { primary-dns 4.2.2.2/32; } } } }
Note: When the connection is established, a secure virtual adapter is generated on the client, which shows the IP address and other xauth attributes that are provided by SRX.
If you require an IPSEC VPN Client for ScreenOS – Juniper Partner with NCP. Its called NCP Secure Client – Juniper Edition
The following is a Juniper KB article about the product.
The original version of the Juniper KB article below is found here:
KB17266
Summary:
Frequently Asked Questions (FAQ) for the NCP Secure Client – Juniper Edition.
Problem or Goal:
Juniper officially announced plans to EOL NS-Remote on June 30, 2009.
A possible remote VPN alternative is the NCP Secure Client. Juniper has entered into a reference sale arrangement with a third party company, NCP engineering, Inc (www.ncp-e.com), whose client has been validated to work with Juniper gateways running ScreenOS.
This article addresses some frequently asked questions related to NCP and NetScreen-Remote (also referred to as NS-Remote and NSR).
Solution:
Refer to the Q & A below, which is divided up into two sections: NCP Related Questions and IPSec and NS-Remote Related Questions.
Q: What IPSec VPN options are available for existing NS-Remote customers?
A: Operating systems like Windows Vista and Windows 7 have a built-in IPSec client. For supported deployment scenarios, built-in IPSec clients have the added advantage of eliminating the need to install and maintain a separate client application.
Operating systems evaluated: Windows XP (32-bit), Windows Vista (32- and 64-bit) and Windows 7 (32-bit)
Windows VPN modes tested: Windows primarily supports remote connections by performing L2TP over IPSec. It does support native IPSec, but it is not the primary way to configure VPNs in Windows. Both modes were tested here for this trial. The results were the same across all four platforms.
L2TP over IPSec: L2TP over IPSec encapsulates user traffic within the L2TP protocol, which is then encrypted with IPSec; since L2TP offers no native encryption. Windows supports two modes of remote access through their primary remote access component. This is L2TP over IPSec and PPTP (not supported by ScreenOS or Junos).
The configuration of the Windows client to a ScreenOS Firewall was successful but with several notable caveats that will limit the use cases it can address. First, L2TP over IPSec does not support NAT-T (at least not with interoperability with the ScreenOS platforms) so this essentially limits it to only connections without NAT. Next, it can only function with ScreenOS by authenticating with Certificates, and will not properly support preshared key authentication based on our testing. This has to do with an inability to properly authenticate the identity with anything except IP address IKE ID. Due to these limitations, it was deemed that L2TP over IPSec can be used if for certain use cases, but would not be a direct replacement for NS-Remote.
Native IPSec: Windows lets you configure true IPSec VPN tunnels natively with IPSec components built into Windows. This configuration is much more challenging than configuring L2TP, as it requires numerous values to be defined primarily through a Microsoft management console configuration. There were several noted limitations on configuring this method. First, the native Windows IPSec does not support XAuth, so this would make it very difficult to implement in a large scalable fashion. Next, support for NAT-T requires modifying the registry. By default, the IPSec client tries to create a VPN tunnel wherever possible (so even if the end system is within the network it will try to create an IPSec tunnel.) This can be undesirable for users who use their machine both locally in the LAN as well as remotely. Additional customization, such as scripting, can be used to improve the behavior
Conclusion: Based on thorough testing of the Windows L2TP over IPSec and native IPSec clients against ScreenOS, the testing engineers concluded that the native clients have not evolved much and that third-party IPSec clients offer a richer feature set supporting a broader range of use cases. Although Microsoft native clients can be used in limited cases, other alternatives should be sought out that can provide standard IPSec capabilities with robust encryption features, XAuth, NAT-T, PSK and certificate authentication, and wide platform support.
• KB17364 – Example configuration of NCP Client
• KB16075 – Configuring a dial-up VPN using Windows 7 client with L2TP over IPSec (without NetScreen-Remote)