Copy and paste the output below onto your SRX series or J Series device in configuration mode.
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.
Please wait...
About This Tool
1.
Fill out all required fields under all the tabs or on the network diagram.
2.
Click on one of the buttons above to generate the configuration.
3.
Copy and paste the generated configuration output onto your SRX series or J series device in configuration mode.
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 VPNtunnel. 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
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.
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.
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.
Select the 'Generate Config' button at the bottom of the form.
The CLI commands for the config will be displayed in another window.
Review the config output.
Copy and paste the commands onto your SRX or J Series device in Configuration Mode.
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.