Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec VPN Configuration Overview

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 or policy-based IPsec VPN using autokey IKE (preshared keys or certificates).

To configure a route-based or policy-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. Configure a security policy to permit traffic from the source zone to the destination zone.

    (For policy-based VPNs) Specify the security policy action tunnel ipsec-vpn with the name of the IPsec VPN tunnel that you configured.

  5. Update your global VPN settings.

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. Starting with Junos OS Release 15.1X49-D80, 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

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. 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.

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.

    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.

  • 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.

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.

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.

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.

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.

Example: Configuring a Hub-and-Spoke VPN

This example shows how to configure a hub-and-spoke IPsec VPN for an enterprise-class deployment. For site-to-site IPSec VPN with IKEv1 and IKEv2, see Route-Based IPsec VPN with IKEv1 and Route-Based IPsec VPN with IKEv1 respectively.

Requirements

This example uses the following hardware:

  • SRX240 device

  • SRX5800 device

  • SSG140 device

Before you begin, read IPsec Overview.

Overview

This example describes how to configure a hub-and-spoke VPN typically found in branch deployments. The hub is the corporate office, and there are two spokes—a branch office in Sunnyvale, California, and a branch office in Westford, Massachusetts. Users in the branch offices will use the VPN to securely transfer data with the corporate office.

Figure 1 shows an example of a hub-and-spoke VPN topology. In this topology, an SRX5800 device is located at the corporate office. An SRX Series Firewall is located at the Westford branch, and an SSG140 device is located at the Sunnyvale branch.

Figure 1: Hub-and-Spoke VPN TopologyHub-and-Spoke VPN Topology

In this example, you configure the corporate office hub, the Westford spoke, and the Sunnyvale spoke. First you configure interfaces, IPv4 static and default routes, security zones, and address books. Then you configure IKE Phase 1 and IPsec Phase 2 parameters, and bind the st0.0 interface to the IPsec VPN. On the hub, you configure st0.0 for multipoint and add a static NHTB table entry for the Sunnyvale spoke. Finally, you configure security policy and TCP-MSS parameters. See Table 4 through Table 8 for specific configuration parameters used in this example.

Table 4: Interface, Security Zone, and Address Book Information

Hub or Spoke

Feature

Name

Configuration Parameters

Hub

Interfaces

ge-0/0/0.0

192.168.10.1/24

   

ge-0/0/3.0

10.1.1.2/30

   

st0

10.11.11.10/24

Spoke

Interfaces

ge-0/0/0.0

10.3.3.2/30

   

ge-0/0/3.0

192.168.178.1/24

   

st0

10.11.11.12/24

Hub

Security zones

trust

  • All system services are allowed.

  • The ge-0/0/0.0 interface is bound to this zone.

   

untrust

  • IKE is the only allowed system service.

  • The ge-0/0/3.0 interface is bound to this zone.

   

vpn

The st0.0 interface is bound to this zone.

Spoke

Security zones

trust

  • All system services are allowed.

  • The ge-0/0/3.0 interface is bound to this zone.

   

untrust

  • IKE is the only allowed system service.

  • The ge-0/0/0.0 interface is bound to this zone.

   

vpn

The st0.0 interface is bound to this zone.

Hub

Address book entries

local-net

  • This address is for the trust zone’s address book.

  • The address for this address book entry is 192.168.10.0/24.

   

sunnyvale-net

  • This address book is for the vpn zone’s address book.

  • The address for this address book entry is 192.168.168.0/24.

   

westford-net

  • This address is for the vpn zone’s address book.

  • The address for this address book entry is 192.168.178.0/24.

Spoke

Address book entries

local-net

  • This address is for the trust zone’s address book.

  • The address for this address book entry is 192.168.168.178.0/24.

   

corp-net

  • This address is for the vpn zone’s address book.

  • The address for this address book entry is 192.168.10.0/24.

   

sunnyvale-net

  • This address is for the vpn zone’s address book.

  • The address for this address book entry is 192.168.168.0/24.

Table 5: IKE Phase 1 Configuration Parameters

Hub or Spoke

Feature

Name

Configuration Parameters

Hub

Proposal

ike-phase1-proposal

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: aes-128-cbc

 

Policy

ike-phase1-policy

  • Mode: main

  • Proposal reference: ike-phase1-proposal

  • IKE Phase 1 policy authentication method: pre-shared-key ascii-text

 

Gateway

gw-westford

  • IKE policy reference: ike-phase1-policy

  • External interface: ge-0/0/3.0

  • Gateway address: 10.3.3.2

   

gw-sunnyvale

  • IKE policy reference: ike-phase1-policy

  • External interface: ge-0/0/3.0

  • Gateway address: 10.2.2.2

Spoke

Proposal

ike-phase1-proposal

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: aes-128-cbc

 

Policy

ike-phase1-policy

  • Mode: main

  • Proposal reference: ike-phase1-proposal

  • IKE Phase 1 policy authentication method: pre-shared-key ascii-text

 

Gateway

gw-corporate

  • IKE policy reference: ike-phase1-policy

  • External interface: ge-0/0/0.0

  • Gateway address: 10.1.1.2

Table 6: IPsec Phase 2 Configuration Parameters

Hub or Spoke

Feature

Name

Configuration Parameters

Hub

Proposal

ipsec-phase2-proposal

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: aes-128-cbc

 

Policy

ipsec-phase2-policy

  • Proposal reference: ipsec-phase2-proposal

  • PFS: Diffie-Hellman group2

 

VPN

vpn-sunnyvale

  • IKE gateway reference: gw-sunnyvale

  • IPsec policy reference: ipsec-phase2-policy

  • Bind to interface: st0.0

   

vpn-westford

  • IKE gateway reference: gw-westford

  • IPsec policy reference: ipsec-phase2-policy

  • Bind to interface: st0.0

Spoke

Proposal

ipsec-phase2-proposal

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: aes-128-cbc

 

Policy

ipsec-phase2-policy

  • Proposal reference: ipsec-phase2-proposal

  • PFS: Diffie-Hellman group2

 

VPN

vpn-corporate

  • IKE gateway reference: gw-corporate

  • IPsec policy reference: ipsec-phase2-policy

  • Bind to interface: st0.0

Table 7: Security Policy Configuration Parameters

Hub or Spoke

Purpose

Name

Configuration Parameters

Hub

The security policy permits traffic from the trust zone to the vpn zone.

local-to-spokes

  • Match criteria:

    • source-address local-net

    • destination-address sunnyvale-net

    • destination-address westford-net

    • application any

 

The security policy permits traffic from the vpn zone to the trust zone.

spokes-to-local

Match criteria:

  • source-address sunnyvale-net

  • source-address westford-net

  • destination-address local-net

  • application any

 

The security policy permits intrazone traffic.

spoke-to-spoke

Match criteria:

  • source-address any

  • destination-address any

  • application any

Spoke

The security policy permits traffic from the trust zone to the vpn zone.

to-corp

  • Match criteria:

    • source-address local-net

    • destination-address corp-net

    • destination-address sunnyvale-net

    • application any

 

The security policy permits traffic from the vpn zone to the trust zone.

from-corp

Match criteria:

  • source-address corp-net

  • source-address sunnyvale-net

  • destination-address local-net

  • application any

 

The security policy permits traffic from the untrust zone to the trust zone.

permit-any

Match criteria:

  • source-address any

  • source-destination any

  • application any

  • Permit action: source-nat interface

    By specifying source-nat interface, the SRX Series Firewall translates the source IP address and port for outgoing traffic, using the IP address of the egress interface as the source IP address and a random high-number port for the source port.

Table 8: TCP-MSS Configuration Parameters

Purpose

Configuration Parameters

TCC-MSS is negotiated as part of the TCP three-way handshake and limits the maximum size of a TCP segment to better fit the MTU limits on a network. For VPN traffic, the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting ESP packet to exceed the MTU of the physical interface, which causes fragmentation. Fragmentation results in increased use of bandwidth and device resources.

The value of 1350 is a recommended starting point for most Ethernet-based networks with an MTU of 1500 or greater. You might need to experiment with different TCP-MSS values to obtain optimal performance. For example, you might need to change the value if any device in the path has a lower MTU, or if there is any additional overhead such as PPP or Frame Relay.

MSS value: 1350

Configuration

Configuring Basic Network, Security Zone, and Address Book Information for the Hub

CLI Quick Configuration

To quickly configure this example, 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 basic network, security zone, and address book information for the hub:

  1. Configure Ethernet interface information.

  2. Configure static route information.

  3. Configure the untrust security zone.

  4. Assign an interface to the untrust security zone.

  5. Specify allowed system services for the untrust security zone.

  6. Configure the trust security zone.

  7. Assign an interface to the trust security zone.

  8. Specify allowed system services for the trust security zone.

  9. Create an address book and attach a zone to it.

  10. Configure the vpn security zone.

  11. Assign an interface to the vpn security zone.

  12. Create another address book and attach a zone to it.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring IKE for the Hub

CLI Quick Configuration

To quickly configure this example, 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 IKE for the hub:

  1. Create the IKE Phase 1 proposal.

  2. Define the IKE proposal authentication method.

  3. Define the IKE proposal Diffie-Hellman group.

  4. Define the IKE proposal authentication algorithm.

  5. Define the IKE proposal encryption algorithm.

  6. Create an IKE Phase 1 policy.

  7. Set the IKE Phase 1 policy mode.

  8. Specify a reference to the IKE proposal.

  9. Define the IKE Phase 1 policy authentication method.

  10. Create an IKE Phase 1 gateway and define its external interface.

  11. Define the IKE Phase 1 policy reference.

  12. Define the IKE Phase 1 gateway address.

  13. Create an IKE Phase 1 gateway and define its external interface.

  14. Define the IKE Phase 1 policy reference.

  15. Define the IKE Phase 1 gateway address.

Results

From configuration mode, confirm your configuration by entering the show security ike command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring IPsec for the Hub

CLI Quick Configuration

To quickly configure this example, 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 IPsec for the hub:

  1. Create an IPsec Phase 2 proposal.

  2. Specify the IPsec Phase 2 proposal protocol.

  3. Specify the IPsec Phase 2 proposal authentication algorithm.

  4. Specify the IPsec Phase 2 proposal encryption algorithm.

  5. Create the IPsec Phase 2 policy.

  6. Specify the IPsec Phase 2 proposal reference.

  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.

  8. Specify the IKE gateways.

  9. Specify the IPsec Phase 2 policies.

  10. Specify the interface to bind.

  11. Configure the st0 interface as multipoint.

  12. Add static NHTB table entries for the Sunnyvale and Westford offices.

Results

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

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

Configuring Security Policies for the Hub

CLI Quick Configuration

To quickly configure this example, 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 security policies for the hub:

  1. Create the security policy to permit traffic from the trust zone to the vpn zone.

  2. Create the security policy to permit traffic from the vpn zone to the trust zone.

  3. Create the security policy to permit intrazone traffic.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring TCP-MSS for the Hub

CLI Quick Configuration

To quickly configure this example, 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

To configure TCP-MSS information for the hub:

  1. Configure TCP-MSS information.

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring Basic Network, Security Zone, and Address Book Information for the Westford Spoke

CLI Quick Configuration

To quickly configure this example, 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 basic network, security zone, and address book information for the Westford spoke:

  1. Configure Ethernet interface information.

  2. Configure static route information.

  3. Configure the untrust security zone.

  4. Assign an interface to the security zone.

  5. Specify allowed system services for the untrust security zone.

  6. Configure the trust security zone.

  7. Assign an interface to the trust security zone.

  8. Specify allowed system services for the trust security zone.

  9. Configure the vpn security zone.

  10. Assign an interface to the vpn security zone.

  11. Create an address book and attach a zone to it.

  12. Create another address book and attach a zone to it.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, and show security address-book commands. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring IKE for the Westford Spoke

CLI Quick Configuration

To quickly configure this example, 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 IKE for the Westford spoke:

  1. Create the IKE Phase 1 proposal.

  2. Define the IKE proposal authentication method.

  3. Define the IKE proposal Diffie-Hellman group.

  4. Define the IKE proposal authentication algorithm.

  5. Define the IKE proposal encryption algorithm.

  6. Create an IKE Phase 1 policy.

  7. Set the IKE Phase 1 policy mode.

  8. Specify a reference to the IKE proposal.

  9. Define the IKE Phase 1 policy authentication method.

  10. Create an IKE Phase 1 gateway and define its external interface.

  11. Define the IKE Phase 1 policy reference.

  12. Define the IKE Phase 1 gateway address.

Results

From configuration mode, confirm your configuration by entering the show security ike command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring IPsec for the Westford Spoke

CLI Quick Configuration

To quickly configure this example, 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 IPsec for the Westford spoke:

  1. Create an IPsec Phase 2 proposal.

  2. Specify the IPsec Phase 2 proposal protocol.

  3. Specify the IPsec Phase 2 proposal authentication algorithm.

  4. Specify the IPsec Phase 2 proposal encryption algorithm.

  5. Create the IPsec Phase 2 policy.

  6. Specify the IPsec Phase 2 proposal reference.

  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.

  8. Specify the IKE gateway.

  9. Specify the IPsec Phase 2 policy.

  10. Specify the interface to bind.

Results

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

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

Configuring Security Policies for the Westford Spoke

CLI Quick Configuration

To quickly configure this example, 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 security policies for the Westford spoke:

  1. Create the security policy to permit traffic from the trust zone to the vpn zone.

  2. Create the security policy to permit traffic from the vpn zone to the trust zone.

Results

From configuration mode, confirm your configuration by entering the show security policies command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring TCP-MSS for the Westford Spoke

CLI Quick Configuration

To quickly configure this example, 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

To configure TCP-MSS for the Westford spoke:

  1. Configure TCP-MSS information.

Results

From configuration mode, confirm your configuration by entering the show security flow command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

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

Configuring the Sunnyvale Spoke

CLI Quick Configuration

This example uses an SSG Series device for the Sunnyvale spoke. For reference, the configuration for the SSG Series device is provided. For information about configuring SSG Series devices, see the Concepts and Examples ScreenOS Reference Guide, which is located at https://www.juniper.net/documentation.

To quickly configure this section of the example, 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.

Verification

To confirm that the configuration is working properly, perform these tasks:

Verifying the IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

Before starting the verification process, you need to send traffic from a host in the 192.168.10/24 network to a host in the 192.168.168/24 and 192.168.178/24 networks to bring the tunnels up. For route-based VPNs, you can send traffic initiated from the SRX Series Firewall through the tunnel. We recommend that when testing IPsec tunnels, you send test traffic from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate a ping from 192.168.10.10 to 192.168.168.10.

From operational mode, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations index index_number detail command.

Meaning

The show security ike security-associations command lists all active IKE Phase 1 SAs. If no SAs are listed, there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration.

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations index detail command to get more information about the SA.

  • Remote Address—Verify that the remote IP address is correct.

  • State

    • UP—The Phase 1 SA has been established.

    • DOWN—There was a problem establishing the Phase 1 SA.

  • Mode—Verify that the correct mode is being used.

Verify that the following information is correct in your configuration:

  • External interfaces (the interface must be the one that receives IKE packets)

  • IKE policy parameters

  • Preshared key information

  • Phase 1 proposal parameters (must match on both peers)

The show security ike security-associations index 1 detail command lists additional information about the security association with an index number of 1:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

  • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)

  • Initiator and responder role information

    Troubleshooting is best performed on the peer using the responder role.

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying the IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

From operational mode, enter the show security ipsec security-associations command. After obtaining an index number from the command, use the show security ipsec security-associations index index_number detail command.

Meaning

The output from the show security ipsec security-associations command lists the following information:

  • The ID number is 16385. Use this value with the show security ipsec security-associations index command to get more information about this particular SA.

  • There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-traversal uses port 4500 or another random high-number port.)

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 28756/ unlim value indicates that the Phase 2 lifetime expires in 28756 seconds, and that no lifesize has been specified, which indicates that it is unlimited. Phase 2 lifetime can differ from Phase 1 lifetime, as Phase 2 is not dependent on Phase 1 after the VPN is up.

  • VPN monitoring is not enabled for this SA, as indicated by a hyphen in the Mon column. If VPN monitoring is enabled, U indicates that monitoring is up, and D indicates that monitoring is down.

  • The virtual system (vsys) is the root system, and it always lists 0.

The output from the show security ipsec security-associations index 16385 detail command lists the following information:

  • The local identity and remote identity make up the proxy ID for the SA.

    A proxy ID mismatch is one of the most common causes for a Phase 2 failure. If no IPsec SA is listed, confirm that Phase 2 proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.

  • Another common reason for Phase 2 failure is not specifying the ST interface binding. If IPsec cannot complete, check the kmd log or set trace options.

Verifying Next-Hop Tunnel Bindings

Purpose

After Phase 2 is complete for all peers, verify the next-hop tunnel bindings.

Action

From operational mode, enter the show security ipsec next-hop-tunnels command.

Meaning

The next-hop gateways are the IP addresses for the st0 interfaces of all remote spoke peers. The next hop should be associated with the correct IPsec VPN name. If no NHTB entry exists, there is no way for the hub device to differentiate which IPsec VPN is associated with which next hop.

The Flag field has one of the following values:

  • Static— NHTB was manually configured in the st0.0 interface configurations, which is required if the peer is not an SRX Series Firewall.

  • Auto— NHTB was not configured, but the entry was automatically populated into the NHTB table during Phase 2 negotiations between two SRX Series Firewalls

There is no NHTB table for any of the spoke sites in this example. From the spoke perspective, the st0 interface is still a point-to-point link with only one IPsec VPN binding.

Verifying Static Routes for Remote Peer Local LANs

Purpose

Verify that the static route references the spoke peer’s st0 IP address.

Action

From operational mode, enter the show route command.

The next hop is the remote peer’s st0 IP address, and both routes point to st0.0 as the outgoing interface.

Reviewing Statistics and Errors for an IPsec Security Association

Purpose

Review ESP and authentication header counters and errors for an IPsec security association.

Action

From operational mode, enter the show security ipsec statistics index command.

You can also use the show security ipsec statistics command to review statistics and errors for all SAs.

To clear all IPsec statistics, use the clear security ipsec statistics command.

Meaning

If you see packet loss issues across a VPN, you can run the show security ipsec statistics or show security ipsec statistics detail command several times to confirm that the encrypted and decrypted packet counters are incrementing. You should also check whether the other error counters are incrementing.

Testing Traffic Flow Across the VPN

Purpose

Verify the traffic flow across the VPN.

Action

You can use the ping command from the SRX Series Firewall to test traffic flow to a remote host PC. Make sure that you specify the source interface so that the route lookup is correct and the appropriate security zones are referenced during policy lookup.

From operational mode, enter the ping command.

You can also use the ping command from the SSG Series device.

Meaning

If the ping command fails from the SRX Series or SSG Series device, there might be a problem with the routing, security policies, end host, or encryption and decryption of ESP packets.

Release History Table
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.