[an error occurred while processing this directive]
SRX & J Series Site-to-Site VPN Configuration Generator
- Home >
- Support >
- SRX & J Series Site-to-Site VPN Configurator
Generated Configuration:
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.
It appears that you are using an older browser.
Juniper recommends that you upgrade your browser for the best experience.
If possible, we recommend using the latest version of
Internet Explorer,
Firefox,
Safari, or
Chrome.
Copyright© 1999-2014 Juniper Networks, Inc. All rights reserved.
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 |
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.
- 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.
R-U-THERE messages are sent at configured intervals regardless of traffic activity between the peers
(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.
(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.