Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

IPsec VPN Configuration Overview

Read this topic to learn about VPN configuration in Junos OS.

A VPN connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN. The traffic that flows between these two points passes through shared resources such as routers, switches, and other network equipment that make up the public WAN. An IPsec tunnel is created between two participant devices to secure VPN communication.

IPsec VPN with Autokey IKE Configuration Overview

IPsec VPN negotiation occurs in two phases. In Phase 1, participants establish a secure channel in which to negotiate the IPsec security association (SA). In Phase 2, participants negotiate the IPsec SA for authenticating traffic that will flow through the tunnel.

This overview describes the basic steps to configure a route-based VPN using autokey IKE (preshared keys or certificates).

To configure a route-based IPsec VPN using autokey IKE:

  1. Configure interfaces, security zones, and address book information.

    (For route-based VPNs) Configure a secure tunnel st0.x interface. Configure routing on the device.

  2. Configure Phase 1 of the IPsec VPN tunnel.
    1. (Optional) Configure a custom IKE Phase 1 proposal. This step is optional, as you can use a predefined IKE Phase 1 proposal set (Standard, Compatible, or Basic).
    2. Configure an IKE policy that references either your custom IKE Phase 1 proposal or a predefined IKE Phase 1 proposal set. Specify autokey IKE preshared key or certificate information. Specify the mode (main or aggressive) for the Phase 1 exchanges.
    3. Configure an IKE gateway that references the IKE policy. Specify the IKE IDs for the local and remote devices. If the IP address of the remote gateway is not known, specify how the remote gateway is to be identified.
  3. Configure Phase 2 of the IPsec VPN tunnel.
    1. (Optional) Configure a custom IPsec Phase 2 proposal. This step is optional, as you can use a predefined IPsec Phase 2 proposal set (Standard, Compatible, or Basic).
    2. Configure an IPsec policy that references either your custom IPsec Phase 2 proposal or a predefined IPsec Phase 2 proposal set. Specify perfect forward secrecy (PFS) keys.
    3. Configure an IPsec VPN tunnel that references both the IKE gateway and the IPsec policy. Specify the proxy IDs to be used in Phase 2 negotiations.

      (For route-based VPNs) Bind the secure tunnel interface st0.x to the IPsec VPN tunnel.

  4. Update your global VPN settings.

See Also

Understanding IPsec VPNs with Dynamic Endpoints

Overview

An IPsec VPN peer can have an IP address that is not known to the peer with which it is establishing the VPN connection. For example, a peer can have an IP address dynamically assigned by means of Dynamic Host Configuration Protocol (DHCP). This could be the case with a remote access client in a branch or home office or a mobile device that moves between different physical locations. Or, the peer can be located behind a NAT device that translates the peer’s original source IP address into a different address. A VPN peer with an unknown IP address is referred to as a dynamic endpoint and a VPN established with a dynamic endpoint is referred to as a dynamic endpoint VPN.

On SRX Series Firewalls, IKEv1 or IKEv2 is supported with dynamic endpoint VPNs. Dynamic endpoint VPNs on SRX Series Firewalls support IPv4 traffic on secure tunnels. Dynamic endpoint VPNs on SRX Series Firewalls support IPv6 traffic on secure tunnels.

IPv6 traffic is not supported for AutoVPN networks.

The following sections describe items to note when configuring a VPN with a dynamic endpoint.

IKE Identity

On the dynamic endpoint, an IKE identity must be configured for the device to identify itself to its peer. The local identity of the dynamic endpoint is verified on the peer. By default, the SRX Series Firewall expects the IKE identity to be one of the following:

  • When certificates are used, a distinguished name (DN) can be used to identify users or an organization.

  • A hostname or fully qualified domain name (FQDN) that identifies the endpoint.

  • A user fully qualified domain name (UFQDN), also known as user-at-hostname. This is a string that follows the e-mail address format.

Aggressive Mode for IKEv1 Policy

When IKEv1 is used with dynamic endpoint VPNs, the IKE policy must be configured for aggressive mode.

IKE Policies and External Interfaces

All dynamic endpoint gateways configured on SRX Series Firewalls that use the same external interface can use different IKE policies, but the IKE policies must use the same IKE proposal. This applies to IKEv1 and IKEv2.

NAT

If the dynamic endpoint is behind a NAT device, NAT-T must be configured on the SRX Series Firewall. NAT keepalives might be required to maintain the NAT translation during the connection between the VPN peers. By default, NAT-T is enabled on SRX Series Firewalls and NAT keepalives are sent at 20-second intervals.

Group and Shared IKE IDs

You can configure an individual VPN tunnel for each dynamic endpoint. For IPv4 dynamic endpoint VPNs, you can use the group IKE ID or shared IKE ID features to allow a number of dynamic endpoints to share an IKE gateway configuration.

The group IKE ID allows you to define a common part of a full IKE ID for all dynamic endpoints, such as “example.net.” A user-specific part, such as the username “Bob,” concatenated with the common part forms a full IKE ID (Bob.example.net) that uniquely identifies each user connection.

The shared IKE ID allows dynamic endpoints to share a single IKE ID and preshared key.

See Also

Understanding IKE Identity Configuration

The IKE identification (IKE ID) is used for validation of VPN peer devices during IKE negotiation. The IKE ID received by the SRX Series Firewall from a remote peer can be an IPv4 or IPv6 address, a hostname, a fully qualified domain name (FQDN), a user FQDN (UFQDN), or a distinguished name (DN). The IKE ID sent by the remote peer needs to match what is expected by the SRX Series Firewall. Otherwise, IKE ID validation fails and the VPN is not established.

IKE ID Types

The SRX Series Firewalls support the following types of IKE identities for remote peers:

  • An IPv4 or IPv6 address is commonly used with site-to-site VPNs, where the remote peer has a static IP address.

  • A hostname is a string that identifies the remote peer system. This can be an FQDN that resolves to an IP address. It can also be a partial FQDN that is used in conjunction with an IKE user type to identify a specific remote user.

    When a hostname is configured instead of an IP address, the committed configuration and subsequent tunnel establishment is based on the currently-resolved IP address. If the remote peer’s IP address changes, the configuration is no longer valid.

  • A UFQDN is a string that follows the same format as an e-mail address, such as user@example.com.

  • A DN is a name used with digital certificates to uniquely identify a user. For example, a DN can be “CN=user, DC=example, DC=com.” Optionally, you can use the container keyword to specify that the order of the fields in a DN and their values exactly match the configured DN, or use the wildcard keyword to specify that the values of fields in a DN must match but the order of the fields does not matter.

    You can now configure only one dynamic DN attribute among container-string and wildcard-string at [edit security ike gateway gateway_name dynamic distinguished-name] hierarchy. If you try configuring the second attribute after you configure the first attribute, the first attribute is replaced with the second attribute. Before your upgrade your device, you must remove one of the attributes if you have configured both the attributes.

  • An IKE user type can be used with AutoVPN and remote access VPNs when there are multiple remote peers connecting to the same VPN gateway on the SRX Series Firewall. Configure ike-user-type group-ike-id to specify a group IKE ID or ike-user-type shared-ike-id to specify a shared IKE ID.

Remote IKE IDs and Site-to-Site VPNs

For site-to-site VPNs, the remote peer’s IKE ID can be the IP address of the egress network interface card, a loopback address, a hostname, or a manually configured IKE ID, depending on the configuration of the peer device.

By default, SRX Series Firewalls expect the remote peer’s IKE ID to be the IP address configured with the set security ike gateway gateway-name address configuration. If the remote peer’s IKE ID is a different value, you need to configure the remote-identity statement at the [edit security ike gateway gateway-name] hierarchy level.

For example, an IKE gateway on the SRX Series Firewalls is configured with the set security ike gateway remote-gateway address 203.0.113.1 command. However, the IKE ID sent by the remote peer is host.example.net. There is a mismatch between what the SRX Series Firewall expects for the remote peer’s IKE ID (203.0.113.1) and the actual IKE ID (host.example.net) sent by the peer. In this case, IKE ID validation fails. Use the set security ike gateway remote-gateway remote-identity hostname host.example.net to match the IKE ID received from the remote peer.

Remote IKE IDs and Dynamic Endpoint VPNs

For dynamic endpoint VPNs, the remote peer’s expected IKE ID is configured with the options at the [edit security ike gateway gateway-name dynamic] hierarchy level. For AutoVPN, hostname combined with ike-user-type group-ike-id can be used where there are multiple peers that have a common domain name. If certificates are used for verifying the peer, a DN can be configured.

Local IKE ID of the SRX Series Firewall

By default, the SRX Series Firewall uses the IP address of its external interface to the remote peer as its IKE ID. This IKE ID can be overridden by configuring the local-identity statement at the [edit security ike gateway gateway-name] hierarchy level. If you need to configure the local-identity statement on an SRX Series Firewall, make sure that the configured IKE ID matches the IKE ID expected by the remote peer.

See Also

Configuring Remote IKE IDs for Site-to-Site VPNs

By default, SRX Series Firewalls validate the IKE ID received from the peer with the IP address configured for the IKE gateway. In certain network setups, the IKE ID received from the peer (which can be an IPv4 or IPv6 address, fully qualified domain name [FQDN], distinguished name, or e-mail address) does not match the IKE gateway configured on the SRX Series Firewall. This can lead to a Phase 1 validation failure.

To modify the configuration of the SRX Series Firewall or the peer device for the IKE ID that is used:

  • On the SRX Series Firewall, configure the remote-identity statement at the [edit security ike gateway gateway-name] hierarchy level to match the IKE ID that is received from the peer. Values can be an IPv4 or IPv6 address, FQDN, distinguished name, or e-mail address.

    If you do not configure remote-identity, the device uses the IPv4 or IPv6 address that corresponds to the remote peer by default.

  • On the peer device, ensure that the IKE ID is the same as the remote-identity configured on the SRX Series Firewall. If the peer device is an SRX Series Firewall, configure the local-identity statement at the [edit security ike gateway gateway-name] hierarchy level. Values can be an IPv4 or IPv6 address, FQDN, distinguished name, or e-mail address.

See Also

Understanding OSPF and OSPFv3 Authentication on SRX Series Firewalls

OSPFv3 does not have a built-in authentication method and relies on the IP Security (IPsec) suite to provide this functionality. IPsec provides authentication of origin, data integrity, confidentiality, replay protection, and nonrepudiation of source. You can use IPsec to secure specific OSPFv3 interfaces and virtual links and to provide encryption for OSPF packets.

OSPFv3 uses the IP authentication header (AH) and the IP Encapsulating Security Payload (ESP) portions of the IPsec protocol to authenticate routing information between peers. AH can provide connectionless integrity and data origin authentication. It also provides protection against replays. AH authenticates as much of the IP header as possible, as well as the upper-level protocol data. However, some IP header fields might change in transit. Because the value of these fields might not be predictable by the sender, they cannot be protected by AH. ESP can provide encryption and limited traffic flow confidentiality or connectionless integrity, data origin authentication, and an anti-replay service.

IPsec is based on security associations (SAs). An SA is a set of IPsec specifications that are negotiated between devices that are establishing an IPsec relationship. This simplex connection provides security services to the packets carried by the SA. These specifications include preferences for the type of authentication, encryption, and IPsec protocol to be used when establishing the IPsec connection. An SA is used to encrypt and authenticate a particular flow in one direction. Therefore, in normal bidirectional traffic, the flows are secured by a pair of SAs. An SA to be used with OSPFv3 must be configured manually and use transport mode. Static values must be configured on both ends of the SA.

To configure IPsec for OSPF or OSPFv3, first define a manual SA with the security-association sa-name option at the [edit security ipsec] hierarchy level. This feature only supports bidirectional manual key SAs in transport mode. Manual SAs require no negotiation between the peers. All values, including the keys, are static and specified in the configuration. Manual SAs statically define the security parameter index (SPI) values, algorithms, and keys to be used and require matching configurations on both endpoints (OSPF or OSPFv3 peers). As a result, each peer must have the same configured options for communication to take place.

The actual choice of encryption and authentication algorithms is left to your IPsec administrator; however, we have the following recommendations:

  • Use ESP with null encryption to provide authentication to protocol headers but not to the IPv6 header, extension headers, and options. With null encryption, you are choosing not to provide encryption on protocol headers. This can be useful for troubleshooting and debugging purposes. For more information about null encryption, see RFC 2410, The NULL Encryption Algorithm and Its Use with IPsec.

  • Use ESP with DES or 3DES for full confidentiality.

  • Use AH to provide authentication to protocol headers, immutable fields in IPv6 headers, and extension headers and options.

The configured SA is applied to the OSPF or OSPFv3 configurations as follows:

  • For an OSPF or OSPFv3 interface, include the ipsec-sa name statement at the [edit protocols ospf area area-id interface interface-name] or [edit protocols ospf3 area area-id interface interface-name] hierarchy level. Only one IPsec SA name can be specified for an OSPF or OSPFv3 interface; however, different OSPF/OSPFv3 interfaces can specify the same IPsec SA.

  • For an OSPF or OSPFv3 virtual link, include the ipsec-sa name statement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id] or [edit protocols ospf3 area area-id virtual-link neighbor-id router-id transit-area area-id] hierarchy level. You must configure the same IPsec SA for all virtual links with the same remote endpoint address.

The following restrictions apply to IPsec authentication for OSPF or OSPFv3 on SRX Series Firewalls:

  • Manual VPN configurations that are configured at the [edit security ipsec vpn vpn-name manual] hierarchy level cannot be applied to OSPF or OSPFv3 interfaces or virtual links to provide IPsec authentication and confidentiality.

  • You cannot configure IPsec for OSPF or OSPFv3 authentication if there is an existing IPsec VPN configured on the device with the same local and remote addresses.

  • IPsec for OSPF or OSPFv3 authentication is not supported over secure tunnel st0 interfaces.

  • Rekeying of manual keys is not supported.

  • Dynamic Internet Key Exchange (IKE) SAs are not supported.

  • Only IPsec transport mode is supported. In transport mode, only the payload (the data you transfer) of the IP packet is encrypted, authenticated, or both. Tunnel mode is not supported.

  • Because only bidirectional manual SAs are supported, all OSPFv3 peers must be configured with the same IPsec SA. You configure a manual bidirectional SA at the [edit security ipsec] hierarchy level.

  • You must configure the same IPsec SA for all virtual links with the same remote endpoint address.

See Also

Example: Configuring IPsec Authentication for an OSPF Interface on an SRX Series Firewall

This example shows how to configure and apply a manual security association (SA) to an OSPF interface.

Requirements

Before you begin:

  • Configure the device interfaces.

  • Configure the router identifiers for the devices in your OSPF network.

  • Control OSPF designated router election.

  • Configure a single-area OSPF network.

  • Configure a multiarea OSPF network.

Overview

You can use IPsec authentication for both OSPF and OSPFv3. You configure the manual SA separately and apply it to the applicable OSPF configuration. Table 3 lists the parameters and values configured for the manual SA in this example.

Table 3: Manual SA for IPsec OSPF Interface Authentication

Parameter

Value

SA name

sa1

Mode

transport

Direction

bidirectional

Protocol

AH

SPI

256

Authentication algorithm

Key

hmac-md5-96

(ASCII) 123456789012abc

Encryption algorithm

Key

des

(ASCII) cba210987654321

Configuration

Configuring a Manual SA

CLI Quick Configuration

To quickly configure a manual SA to be used for IPsec authentication on an OSPF interface, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure a manual SA:

  1. Specify a name for the SA.

  2. Specify the mode of the manual SA.

  3. Configure the direction of the manual SA.

  4. Configure the IPsec protocol to use.

  5. Configure the value of the SPI.

  6. Configure the authentication algorithm and key.

  7. Configure the encryption algorithm and key.

Results

Confirm your configuration by entering the show security ipsec command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

After you configure the password, you do not see the password itself. The output displays the encrypted form of the password you configured.

If you are done configuring the device, enter commit from configuration mode.

Enabling IPsec Authentication for an OSPF Interface

CLI Quick Configuration

To quickly apply a manual SA used for IPsec authentication to an OSPF interface, copy the following command, paste it into a text file, change any details necessary to match your network configuration, copy and paste the command into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Step-by-Step Procedure

To enable IPsec authentication for an OSPF interface:

  1. Create an OSPF area.

    To specify OSPFv3, include the ospf3 statement at the [edit protocols] hierarchy level.

  2. Specify the interface.

  3. Apply the IPsec manual SA.

Results

Confirm your configuration by entering the show ospf interface detail command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

To confirm your OSPFv3 configuration, enter the show protocols ospf3 command.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the IPsec Security Association Settings

Purpose

Verify the configured IPsec security association settings. Verify the following information:

  • The Security association field displays the name of the configured security association.

  • The SPI field displays the value you configured.

  • The Mode field displays transport mode.

  • The Type field displays manual as the type of security association.

Action

From operational mode, enter the show ospf interface detail command.

Verifying the IPsec Security Association on the OSPF Interface

Purpose

Verify that the IPsec security association that you configured has been applied to the OSPF interface. Confirm that the IPsec SA name field displays the name of the configured IPsec security association.

Action

From operational mode, enter the show ospf interface detail command for OSPF, and enter the show ospf3 interface detail command for OSPFv3.

See Also

Configuring IPsec VPN Using the VPN Wizard

The VPN Wizard enables you to perform basic IPsec VPN configuration, including both Phase 1 and Phase 2. For more advanced configuration, use the J-Web interface or the CLI. This feature is supported on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices.

To configure IPsec VPN using the VPN Wizard:

  1. Select Configure>Device Setup>VPN in the J-Web interface.
  2. Click the Launch VPN Wizard button.
  3. Follow the wizard prompts.

The upper left area of the wizard page shows where you are in the configuration process. The lower left area of the page shows field-sensitive help. When you click a link under the Resources heading, the document opens in your browser. If the document opens in a new tab, be sure to close only the tab (not the browser window) when you close the document.

See Also

Related Documentation

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.4R1
Starting in Junos OS Release 19.4R1, you can now configure only one dynamic DN attribute among container-string and wildcard-string at [edit security ike gateway gateway_name dynamic distinguished-name] hierarchy. If you try configuring the second attribute after you configure the first attribute, the first attribute is replaced with the second attribute. Before your upgrade your device, you must remove one of the attributes if you have configured both the attributes.
15.1X49-D80
Starting with Junos OS Release 15.1X49-D80, dynamic endpoint VPNs on SRX Series Firewalls support IPv6 traffic on secure tunnels.
12.3X48-D40
Starting with Junos OS Release 12.3X48-D40, Junos OS Release 15.1X49-D70, and Junos OS Release 17.3R1, all dynamic endpoint gateways configured on SRX Series Firewalls that use the same external interface can use different IKE policies, but the IKE policies must use the same IKE proposal.