VPN Type
Choose a Route-Based or Policy Based VPN configuration

Route-Based VPN:

With route-based VPNs, a policy does not specifically reference a VPN tunnel. Instead, the policy references a destination address. When the security device does a route lookup to find the interface through which it must send traffic to reach that address, it finds a route via a secure tunnel (st0) interface, which is bound to a specific VPN tunnel. In a route-based VPN tunnel, you can consider a tunnel as a means for delivering traffic, and the policy as a method for either permitting or denying the delivery of that traffic.

Common Reasons to use a Route-based VPN:

Source or Destination NAT (NAT-Src, NAT-Dst) needs to occur as it traverses the VPN

Overlapping Subnets/IP Addresses between the two LANs

Hub-and-spoke VPN topology

Design requires Primary and Backup VPN

A Dynamic Routing Protocol (i.e. OSPF, RIP, BGP) is running across the VPN

Need to access multiple subnets or networks at the remote site, across the VPN

Policy-Based VPN:

With policy-based VPN tunnels, a tunnel is treated as an object that together with source, destination, application, and action, comprises a tunnel policy that permits VPN traffic. In a policy-based VPN configuration, a tunnel policy specifically references a VPN tunnel by name. In a policy-based VPN tunnel, you can consider a tunnel as an element in the construction of a policy.

Common Reasons to use a Policy-based VPN:

Remote VPN device is a non-Juniper device

Need to access only one subnet or one network at the remote site, across the VPN

You require more granularity than a route can provide when determining which traffic is sent to a tunnel

For more information on the difference between a Route-based VPN and a Policy-based VPN on Junos OS, refer to KB10105.

VPN Endpoints
This selection choice is used to determine how the local and remote endpoints in the unencrypted zone are connected. This will be used for VPN Gateway configuration.

• Local Static IP <<-->> Remote Static IP : Local and Remote endpoints use static IP addresses
• Local Static IP <<-->> Remote Dynamic IP : Local endpoint use static IP, Remote endpoint use Dynamic IP
• Local Dynamic IP <<-->> Local Static IP : Local endpoint use Dynamic IP addressing, Remote endpoint use static IP

a) Remote User ID:
• User ID string identifying the remote endpoint when Dynamic IP addressing is used.
  b) Local User ID:
• User ID string identifying the local endpoint when Dynamic IP addressing is used.

Local Private Network
The zone name in which the private or trusted network(s) is located, at the local site.
e.g. trust

In other words, the zone name used to refer the private network at the local site that will connect to the remote site through the VPN. The zone name used to refer the private network at local site that will connect to the remote site through VPN.


TIP: Click on the first input field to see where this field exists in a network diagram.

Public Network Zone
The zone name used to refer the unencrypted public network (i.e. internet)
e.g. untrust
The zone that is bound to the interface that the remote peer device is reachable from at local site.

Public Network Interface
The interface on the device through which the public network is connected.

Nomenclature:

• ge-#/#/#
• ge-#/#/#.#
• fe-#/#/#
• fe-#/#/#.#
• xe-#/#/#
• xe-#/#/#.#
• reth#
• reth#.#
• lo#
• lo#.#

TIP: Click on the first input field to see where this field exists in a network diagram.

Tunnel Zone
The zone name used to refer the secure tunnel for policy management of encrypted traffic.

The zone name used to refer the secure tunnel for policy management of encrypted traffic.

Tunnel Interface:

The secure tunnel interface identifier on the local device. In other words, the tunnel interface to which the route-based virtual private network (VPN) will be bound. (e.g., st0.0)

Valid values for st0 unit: range 0-65535

Tunnel Interface Type:

Numbered
Numbered tunnel interfaces are recommended for the following scenarios:

Source or Destination NAT (NAT-Src, NAT-Dst) occurs as it traverses the VPN

Overlapping Subnets/IP Addresses between the two LANs

A Dynamic Routing Protocol (i.e. OSPF, RIP, BGP) is running across the VPN

It is recommended to be on the same logical subnet of the peer interface on the remote device.

Unnumbered
Unnumbered tunnel interfaces are simplier and used in a small topology environment.

TIP: Click the first input field to see where this field exists in a network diagram.

Tunnel Interface Type
A secure tunnel (st0) is considered numbered when an IP is associated for use on the secure tunnel such as when needed for dynamic routing or interface NAT.

An unnumbered tunnel has no specific IP association to the tunnel. When using unnumbered tunnels the device will use select IP from another interface when needing to generate self over the secure tunnel.

Tunnel Interface IP
The IP address on the secure tunnel interface. It is recommended to be on the same logical subnet of the peer interface on the remote device.

TIP: Click the first input field to see where this field exists in a network diagram.

Local Private Network
The network or host IP address at the local site that will connect to the remote site through the VPN.

To add additional local networks or host IP addresses at the local site, click the 'Add' link. The number of 'local private networks' does not have to equal the number of 'remote private networks'.


TIP: Click the first input field to see where this field exists in a network diagram.

Remote Private Network
The network or host IP address at the remote site that will connect to the local site through the VPN.

To add additional local networks or host IP addresses at the local site, click the 'Add' link.

Possible values:

md5:	MD5 Authentication Algorithm
sha-256:	SHA 256-bit Authentication Algorithm
sha1:	SHA1 Authentication Algorithm

Unique string to append to object names in the configuration.

For example, if the value "cfgr" is specified, the objects will use cfgr in the name:

set security zones security-zone trusting address-book address net-cfgr_5-5-5-1--32 5.5.5.1/32
set security ike proposal ike-proposal-cfgr authentication-method pre-shared-keys

Specify the Diffie-Hellman group.
(Optional)
Possible values:
group 1
group 2
group 5

NAT-T
Enable Network Address Translation-Traversal (NAT-T). For more information, refer to Understanding NAT-T.

Policy Direction
Choose the direction on which the security policy should be applied to.

• Both
  The Policy will be applied to both directions.
  
  
• Outbound
  For a route-based VPN, the policy will be applied from 'local private network zone' to 'secure tunnel zone' (outbound to remote site)
  For a policy-based VPN, the policy will be applied from 'local private network zone' to 'public network zone zone' (outbound to remote site)
  
  
• Inbound
  For a route-based VPN, the policy will be applied from 'secure tunnel zone' to 'local private network zone' (inbound to local site)
  For a policy-based VPN, the policy will be applied from 'public network zone' to 'local private network zone' (inbound to local site)

Possible values:

3des-cbc:	3DES-CBC Encryption Algorithm
aes-128-cbc :	AES-CBC 128-bit Encryption Algorithm
aes-192-cbc:	AES-CBC 192-bit Encryption Algorithm
aes-256-cbc:	AES-CBC 256-bit Encryption Algorithm
des-cbc:	DES-CBC Encryption Algorithm

Type of configuration performed ?
Route-based VPN Policy-based VPN
Please rate this VPN Configuration Tool
Great Good Average Fair Poor
How could the VPN Configurator be improved (or other comments)?
How did you find the VPN Configurator tool?
Juniper Networks main Support home page link Juniper Networks Knowledge Base article/link/whatever Juniper Networks marketing for the tool (email, J-Net, Facebook, Twitter, etc.) Word of mouth/recommended by a friend or co-worker Google Another non-google internet search engine Some other way

Your response will be used to improve our VPN Configuration Tool.

Version 1.0:

• Initial version given to client, PHP support required.

Version 1.1:

• Minor fixes on output buffer handling. Handle firefox's inability to render images
• Fixed - Reset button acting same as the form submit button
• Other corrections

Version 1.2:

• Internal changes, Infosys

Version 1.3:

• Code completely rewritten based on Javascript DOM, because of the unavailability of PHP support at client site.
• Redesigned the form to add toggle support for route-based and policy-based configurations
• Optional PHP support to render dynamic network preview.
• Code completely runs on JS DOM, in case of PHP availability this version has the capability to generate dynamic network image preview.
• Few other requested gui design changes

Version 1.4:

• Added support for selecting multiple applications.

Version 1.5:

• Added support for selecting multiple local and remote private networks.

Version 1.6:

• Incorporated client feedback.

Version 1.7:

• Incorporated client feedback.
• Added support for configuration generation based on the BRD.

IKE Pre-shared Secret (ASCII)
The pre-shared ASCII key used for IKE negotiations between the VPN endpoints.

Possible values:

hmac-md5-96:	HMAC-MD5-96 authentication algorithm
hmac-sha1-96:	HMAC-SHA1-96 authentication algorithm

Possible values:

3des-cbc:	3DES-CBC encryption algorithm
aes-128-cbc :	AES-CBC 128-bit encryption algorithm
aes-192-cbc:	AES-CBC 192-bit encryption algorithm
aes-256-cbc:	AES-CBC 256-bit encryption algorithm
des-cbc:	DES-CBC encryption algorithm

IPsec Security Level
The proposal set used for phase 2 (IPSec) gateway settings.
The predefined proposal sets include the following proposals.

• basic
• Proposal 1— nopfs, esp, des, sha
• Proposal 2— nopfs, esp, des, md5


• compatible
• Proposal 1— nopfs, esp, 3des, sha,
• Proposal 2— nopfs, esp, 3des, md5
• Proposal 3— nopfs, esp, des, sha
• Proposal 4— nopfs, esp, des, md5


• Standard
• Proposal 1— pfs group 2, esp, 3des. sha
• Proposal 2— pfs group 2, esp, aes128, sha


• suiteb-gcm-128 (Available in Junos OS 12.1X45 and higher)
• Encapsulating Security Payload (ESP) protocol
• Encryption algorithm—Advanced Encryption Standard Galois/Counter mode (AES-GCM)128-bit
• Authentication algorithm—None (AES-GCM provides both encryption and authentication)


• suiteb-gcm-256 (Available in Junos OS 12.1X45 and higher)
• ESP protocol
• Encryption algorithm—AES-GCM 256-bit
• Authentication algorithm—None (AES-GCM provides both encryption and authentication)

IKE Security Level
The proposal set used for phase 1 (IKE) gateway settings.
The predefined proposal sets include the following proposals.

• Basic
• Proposal 1 - Preshared key, Data Encryption Standard (DES) encryption, and Diffie-Hellman (DH) group 1 and Secure Hash Algorithm 1 (SHA-1) authentication.
• Proposal 2 - Preshared key, DES encryption, and DH group 1 and Message Digest 5 (MD5) authentication.

• Compatible
• Proposal 1 - Preshared key, triple DES (3DES) encrytption, and Gnutella2 (GS) and SHA-1 authentication.
• Proposal 2 - Preshared key, 3DES encryption, and DH group 2 and MD5 authentication.
• Proposal 3 - Preshared key, DES encryption, and DH group 2 and SHA-1 authentication.
• Proposal 4 - Preshared key, DES encryption, and DH group 2 and MD5 authentication.

• Standard
• Proposal - 1 Preshared key, 3DES encryption, and DH group 2 and SHA-1 authentication.
• Proposal - 2 Preshared key, Advanced Encryption Standard (AES) 128-bit encryption, and DH group 2 and SHA-1 authentication.

• Suite-gcm-128 (Available in Junos OS 12.1X45 and higher)
• Authentication method - Elliptic Curve Digital Signal Algorithm (ECDSA) 256-bit signatures.
• Diffie-Hellman Group - 19
• Encryption algorithm - Advanced Encryption Standard (AES) 128-bit cipher block chaining (CBC)
• Authentication algorithm - SHA - 256

• Suite-gcm-256 (Available in Junos OS 12.1X45 and higher)
• Authentication method - ECDSA 384-bit signatures
• Diffie-Hellman Group - 20
• Encryption algorithm - AES 256 bit CBC
• Authentication algorithm - SHA-384

An user-defined proposal may be created to allow customizable settings. includes preshared-group2-3des-sha1 and preshared-group2-aes128-sha1 proposals. However a unique proposal may be created and then specified in the IKE policy in accordance with your corporate security policy.

Specify the lifetime (in seconds).
(Optional)
Range: 180 to 86400

Specify the lifetime (in seconds) of an IPsec security association (SA).
(Optional)
Range: 180 to 86400

Multiple Phase 2 SAs
Multiple Phase 2 SA option, available on Policy-Based VPN configurations, allows for the creation of multiple security policies for each local private network and remote private network pairing. Multiple Phase 2 SA option is commonly used when the remote VPN device is a non-Juniper device using multiple proxy-ids.

When Multiple Phase 2 SA is not selected generator will build 1 security policy encompassing all local private network and remote private networks resulting in 1 VPN with Proxy-ID of 0.0.0.0/0 for local and remote.

Establish Tunnel
Specify when IKE is activated: immediately - after VPN information is configured and configuration changes are committed on-traffic - only when data traffic flow cause need for the tunnel to be established

This is a stand-alone tool to assist with Site to Site VPN configurations on your SRX or J Series Device.

1. Fill out the fields in the form.
   TIP: Click the 'Network Diagram' in the right column to map the fields in the form to a visual network example.
2. Select the 'Generate Config' button at the bottom of the form.
3. The CLI commands for the config will be displayed in another window.
4. Review the config output.
5. Copy and paste the commands onto your SRX or J Series device in Configuration Mode.
6. If the remote VPN device is also a SRX or J Series device, repeat steps 1-5 for the remote device.

Beta2 Enhancements - 11 Jan 2010:

• Added option to specify DH group and Lifetime to IKE VPN settings
• Added option to specify PFS and Lifetime to IPsec VPN settings

IMPORTANT NOTE: This tool does not perform error checking against your existing configuration.
If a misspelled or incorrect zone, interface or network address is specified, it may report errors when you copy the configuration onto your device

IPsec Perfect Forward Secrecy
Specify Perfect Forward Secrecy (PFS) as the method that the device uses to generate the encryption key. PFS generates each new encryption key independently from the previous key.

(Optional)
Possible values:
group 1
group 2
group 5
group 14
group 19
group 20
group 24

Remote Router's Public IP
IP address of the remote router's interface connecting to the unencrypted public network.

Permitted Services
This is used to configure security policies for the tunnel traffic. You can choose specific application for permit or 'any' for allowing all traffic. A security policy permits traffic in one direction but also allows all reply traffic without the need for a reverse direction policy. However since traffic may be initiated from either direction, bi-directional policies are required.

IKE Mode
Select IKE mode used during IKE Phase 1 exchange.
Main Mode— (default) The initiator and recipient send three two-way exchanges (six messages total) to accomplish the following services:

• First exchange (messages 1 and 2—Propose and accept the encryption and authentication algorithms.
  

• Second exchange (messages 3 and 4—Execute a Diffie-Hellman exchange, and the initiator and recipient each provide a pseudo-random number.

• Third exchange (messages 5 and 6)—Send and verify their identities.

Aggressive Mode—The initiator and recipient accomplish the same objectives, but in only two exchanges, with a total of three messages:

• First message—The initiator proposes the SA, initiates a Diffie-Hellman exchange, and sends a pseudo-random number and its IKE identity.

• Second message—The recipient accepts the SA; authenticates the initiator; and sends a pseudo-random number, its IKE identity, and, if using certificates, the recipient's certificate.

• Third message—The initiator authenticates the recipient, confirms the exchange, and, if using certificates, sends the initiator's certificate.

When using Aggressive Mode the participants' identities are exchanged in the clear (in the first two messages) as such Aggressive mode does not provide identity protection. Note: When using Remote Dynamic IP Aggressive Mode must be used.

IKE Version
A remote peer is configured as either IKEv1 or IKEv2. When a peer is configured as IKEv2, it cannot fall back to IKEv1 if the peer initiates IKEv1 negotiation.
The default value for the version IKEv1.

Note: IKEv2 cannot be selected for Policy-based VPN

Remote IKE ID
Specify the remote IKE identity that peer use during the IKE exchange.
If Unknown is selected, 'general-ike-id' setting will be used to allow acceptance of any received IKE-IDE sent by peer.
Available remote IKE-IDE types for which to specify the values being sent by the peer are:

• hostname: fully-qualified domain name.
• inet: IPV4 address
• inet6: IPV6 address
• user-at-hostname: E-mail address

Note: By default most devices to using IP address of interface connecting to public network for their IKE-ID.

Proxy IDs Manual Entry
For route-based VPNs, specify the local and remote IPsec proxy-ID for use in negotiation with peer.
If no manual proxy-id is entered the system will use a default proxy-id of use 0.0.0.0/0 for local and remote and ‘any’ for service.

VPN Monitor
VPN monitoring is a Junos OS mechanism that monitors only Phase 2 security associations (SAs) by the use of sending ICMP packets over the VPN tunnel.

The optimized option enables the device to use traffic patterns as evidence of peer liveliness thereby suppressing sending of ICMP requests. The interval option allows adjusting how often to send ICMP request. Default is 10 seconds.

The threshold option allows adjusting the number of consecutive unsuccessful pings before VPN Phase 2 is declared down. Default is 10 pings.

Dead Peer Detection
Used to enable dead peer detection (DPD). DPD is a method used by devices to verify the current existence and availability of IPsec peers. A device performs this verification by sending encrypted IKE Phase 1 notification payloads (R-U-THERE messages) to a peer and waiting for DPD acknowledgements (R-U-THERE-ACK messages) from the peer.

The type option allows adjusting DPD mode using the following.

• Always send

R-U-THERE messages are sent at configured intervals regardless of traffic activity between the peers

• Optimized

(Available in Junos OS 12.1X46 and higher)

R-U-THERE messages are triggered if there is no incoming IKE or IPsec traffic within a configured interval after the device sends outgoing packets to the peer. This is the default mode.

• Probe idle tunnel

(Available in Junos OS 12.1X46 and higher)

R-U-THERE messages are triggered if there is no incoming or outgoing IKE or IPsec traffic within a configured interval. R-U-THERE messages are sent periodically to the peer until there is traffic activity. This mode helps in early detection of a downed peer and makes the tunnel available for data traffic.

The interval option allows adjusting how long to wait for traffic from peer before sending R-U-THERE messages. Default is 10 seconds.
The threshold option allows adjusting the number of consecutive unsuccessful responses from R-U-THERE messages before VPN is declared down. Default is 5 transmissions.