Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

IPv6 IPsec VPNs

Juniper Networks supports manual and autokey IKE with preshared keys configurations for IPv6 IPsec VPN.

VPN Feature Support for IPv6 Addresses

A route-based site-to-site VPN tunnel with a point-to-point secure tunnel interface can operate in IPv4-in-IPv4, IPv6-in-IPv6, IPv6-in-IPv4, or IPv4-in-IPv6 tunnel modes. IPv6 addresses can be in the outer IP header, which represents the tunnel endpoint, or in the inner IP header, which represents the final source and destination addresses for a packet.

Table 1 defines the support for IPv6 addresses in VPN features.

Table 1: IPv6 Address Support in VPN Features

Feature

Supported

Exceptions

IKE and IPsec Support:

IKEv1 and IKEv2

Yes

Unless specified, all supported features are applicable for IKEv1 and IKEv2.

Route-based VPN

Yes

–

Policy-based VPN

Yes

IPv6 policy-based VPNs are not supported on SRX Series Firewalls in chassis cluster configurations. IPv6 policy-based VPNs are only supported with IPv6-in-IPv6 tunnels on standalone SRX300, SRX320, SRX340, SRX345, and SRX550HM devices.

Site-to-site VPN

Yes

Only one-to-one, site-to-site VPN is supported. Many-to-one, site-to-site VPN (NHTB) is not supported. NHTB configuration cannot be committed for tunnel modes other than IPv4-in-IPv4 tunnels.

Dynamic endpoint VPN

Yes

–

Dialup VPN

Yes

–

AutoVPN

Yes

AutoVPN networks that use secure tunnel interfaces in point-to-point mode support IPv6 addresses for traffic selectors and for IKE peers. AutoVPN in point-to-multipoint mode does not support IPv6 traffic.

Group VPN

No

–

Point-to-point tunnel interfaces

Yes

–

Point-to-multipoint tunnel interfaces

No

–

Hub-and-spoke scenario for site-to-site VPNs

Yes

–

Numbered and unnumbered tunnel interfaces

Yes

–

Unicast static and dynamic (RIP, OSPF, BGP) routing

Yes

–

Multicast dynamic routing (PIM)

No

–

Virtual router

Yes

–

Logical system

No

–

Automatic and manual SA and key management

Yes

–

Multiple SPUs

Yes

–

Chassis cluster

Yes

IPsec VPN with active-active mode is supported only on SRX300, SRX320, SRX340, SRX345, and SRX550HM devices for route-based IPv6 tunnels. IPsec VPN with active-active mode is not supported on SRX5400, SRX5600, and SRX5800 devices.

Statistics, logs, per-tunnel debugging

Yes

–

SNMP MIB

Yes

–

Local address selection

Yes

When multiple addresses in the same address family are configured on a physical external interface to a VPN peer, we recommend that you also configure local-address at the [edit security ike gateway gateway-name] hierarchy level.

Loopback address termination

Yes

–

Xauth or modecfg over IPv6

No

–

SPC insert

Yes

–

ISSU

Yes

–

DNS name as IKE gateway address

Yes

As with IPv4 tunnels, peer gateway address changes in the DNS name are not supported with IPv6 tunnels.

Preshared key or certificate authentication

Yes

–

NAT-Traversal (NAT-T) for IPv4 IKE peers

Yes

NAT-T is supported only for IPv6-in-IPv4 and IPv4-in-IPv4 tunnel modes with IKEv1. IPv6-in-IPv6 and IPv4-in-IPv6 tunnel modes are not supported. IKEv2 is not supported for NAT-T. NAT-T from IPv6 to IPv4 or from IPv4 to IPv6 is not supported.

Dead peer detection (DPD) and DPD gateway failover

Yes

DPD gateway failover is only supported for different gateway addresses within the same family. Failover from an IPv6 gateway address to an IPv4 gateway address, or vice versa, is not supported.

Encryption sets, authentication algorithms, and DH groups supported in Junos OS Release 12.1X45-D10 release for SRX Series Firewalls.

Yes

–

Generic proposals and policies for IPv6 and IPv4

Yes

–

General IKE ID

Yes

–

ESP and AH transport modes

No

These modes are not supported for IPv4.

ESP and AH tunnel modes

Yes

AH tunnel mode with mutable extension headers and options is not supported.

Extended sequence number

No

–

Single proxy ID pairs

Yes

–

Multiple traffic selector pairs

Yes

Supported with IKEv1 only.

Lifetime of IKE or IPsec SA, in seconds

Yes

–

Lifetime of IKE SA, in kilobytes

Yes

–

VPN monitoring

No

Configuration with IPv6 tunnels cannot be committed.

DF bit

Yes

For IPv6-in-IPv6 tunnels, the DF bit is set only if configured at the [edit security ipsec vpn vpn-name] hierarchy level. df-bit clear is the default.

Dual-stack (parallel IPv4 and IPv6 tunnels) over a single physical interface

Yes

For route-based site-to-site VPNs. A single IPv4 tunnel can operate in both IPv4-in-IPv4 and IPv6-in-IPv4 tunnel modes and a single IPv6 tunnel can operate in both IPv4-in-IPv6 and IPv6-in-IPv6 tunnel modes.

IPv6 extension headers

Yes

IPv6 extension headers and IPv4 options for IKE and IPsec packets are accepted but are not processed. AH with mutable EHs and options is not supported.

Fragmentation and reassembly

Yes

–

VPN session affinity

Yes

–

Multicast traffic

No

–

Tunnel IP services (Screen, NAT, ALG, IPS, AppSecure)

Yes

–

Packet reordering for IPv6 fragments over tunnel

No

–

Bidirectional Forwarding Detection (BFD) over OSPFv3 routes on st0 interface

No

–

Neighbor Discovery Protocol (NDP) over st0 interfaces

No

–

PKI Support:

PKI in virtual router

Yes

–

RSA signature authentication (512-, 1024-, 2048-, or 4096-bit key size)

Yes

–

DSA signature authentication (1024-, 2048-, or 4096-bit key size)

Yes

–

ECDSA signatures

Yes

–

Certificate chain authentication

No

–

Automatic or manual enrollment over IPv4

Yes

–

Automatic or manual revocation over IPv4

Yes

–

Automatic or manual enrollment over IPv6

No

–

Automatic or manual revocation over IPv6

No

–

IPv6 addresses within PKI certificate fields

No

–

See Also

Understanding IPv6 IKE and IPsec Packet Processing

This topic includes the following sections:

IPv6 IKE Packet Processing

Internet Key Exchange (IKE) is part of the IPsec suite of protocols. It automatically enables two tunnel endpoints to set up security associations (SAs) and negotiate secret keys with each other. There is no need to manually configure the security parameters. IKE also provides authentication for communicating peers.

IKE packet processing in IPv6 networks involves the following elements:

  • Internet Security Association and Key Management Protocol (ISAKMP) Identification Payload

    ISAKMP identification payload is used to identify and authenticate the communicating IPv6 peers. Two ID types (ID_IPV6_ADDR and ID_IPV6_ADDR_SUBNET) are enabled for IPv6. The ID type indicates the type of identification to be used. The ID_IPV6_ADDR type specifies a single 16-octet IPv6 address. This ID type represents an IPv6 address. The ID_IPV6_ADDR_SUBNET type specifies a range of IPv6 addresses represented by two 16-octet values. This ID type represents an IPv6 network mask. Table 2 lists the ID types and their assigned values in the identification payload.

    Table 2: ISAKMP ID Types and Their Values

    ID Type

    Value

    RESERVED

    0

    ID_IPV4_ADDR

    1

    ID_FQDN

    2

    ID_USER_FQDN

    3

    ID_IPV4_ADDR_SUBNET

    4

    ID_IPV6_ADDR

    5

    ID_IPV6_ADDR_SUBNET

    6

    ID_IPV4_ADDR_RANGE

    7

    ID_IPV6_ADDR_RANGE

    8

    ID_DER_ASN1_DN

    9

    ID_DER_ASN1_GN

    10

    ID_KEY_ID

    11

    ID_LIST

    12

    The ID_IPV6_ADDR_RANGE type specifies a range of IPv6 addresses represented by two 16-octet values. The first octet value represents the starting IPv6 address and the second octet value represents the ending IPv6 address in the range. All IPv6 addresses falling between the first and last IPv6 addresses are considered to be part of the list.

    Two ID types in ISAKMP identification payload (ID_IPV6_ADDR_RANGE and ID_IPV4_ADDR_RANGE) are not supported in this release.

  • Proxy ID

    A proxy ID is used during Phase 2 of IKE negotiation. It is generated before an IPsec tunnel is established. A proxy ID identifies the SA to be used for the VPN. Two proxy IDs are generated—local and remote. The local proxy ID refers to the local IPv4 or IPv6 address/network and subnet mask. The remote proxy ID refers to the remote IPv4 or IPv6 address/network and subnet mask.

  • Security Association

    An SA is an agreement between VPN participants to support secure communication. SAs are differentiated based on three parameters—security parameter index (SPI), destination IPv6 address, and security protocol (either AH or ESP). The SPI is a unique value assigned to an SA to help identify an SA among multiple SAs. In an IPv6 packet, the SA is identified from the destination address in the outer IPv6 header and the security protocol is identified from either the AH or the ESP header.

IPv6 IPsec Packet Processing

After IKE negotiations are completed and the two IKE gateways have established Phase 1 and Phase 2 SAs, IPv6 IPsec employs authentication and encryption technologies to secure the IPv6 packets. Because IPv6 addresses are 128 bits long compared to IPv4 addresses, which are 32-bits long, IPv6 IPsec packet processing requires more resources.

Packet reordering for IPv6 fragments over a tunnel is not supported.

Devices with IPv6 addressing do not perform fragmentation. IPv6 hosts should either perform path MTU discovery or send packets smaller than the IPv6 minimum MTU size of 1280 bytes.

This topic includes the following sections:

AH Protocol in IPv6

The AH protocol provides data integrity and data authentication for IPv6 packets. IPv6 IPsec uses extension headers (for example, hop-by-hop and routing options) that must be arranged in a particular way in the IPv6 datagram. In AH tunnel mode, the AH header immediately follows the new outer IPv6 header similar to that in IPv4 AH tunnel mode. The extension headers are placed after the original inner header. Therefore, in AH tunnel mode, the entire packet is encapsulated by adding a new outer IPv6 header, followed by an authentication header, an inner header, extension headers, and the rest of the original datagram as shown in Figure 1.

Figure 1: IPv6 AH Tunnel ModeIPv6 AH Tunnel Mode

Unlike ESP, the AH authentication algorithm covers the outer header as well as any new extension headers and options.

AH tunnel mode on SRX Series Firewalls does not support IPv4 mutable options or IPv6 mutable extension headers. See Table 3.

ESP Protocol in IPv6

ESP protocol provides both encryption and authentication for IPv6 packets. Because IPv6 IPsec uses extension headers (for example, hop-by-hop and routing options) in the IPv6 datagram, the most important difference between IPv6 ESP tunnel mode and IPv4 ESP tunnel mode is the placement of extension headers in the packet layout. In ESP tunnel mode, the ESP header immediately follows the new outer IPv6 header similar to that in IPv4 ESP tunnel mode. Therefore, in ESP tunnel mode, the entire packet is encapsulated by adding a new outer IPv6 header, followed by an ESP header, an inner header, extension headers, and the rest of the original datagram as shown in Figure 2.

Figure 2: IPv6 ESP Tunnel ModeIPv6 ESP Tunnel Mode

IPv4 Options and IPv6 Extension Headers with AH and ESP

IPsec packets with IPv4 options or IPv6 extension headers can be received for decapsulation on SRX Series Firewalls. Table 3 shows the IPv4 options or IPv6 extension headers that are supported with the ESP or AH protocol on SRX Series Firewalls. If an unsupported IPsec packet is received, ICV calculation fails and the packet is dropped.

Table 3: Support for IPv4 Options or IPv6 Extension Headers

Options or Extension Headers

SRX300, SRX320, SRX340, SRX345, and SRX550HM Devices

SRX5400, SRX5600, and SRX5800 Devices

ESP with IPv4 options

Supported

Supported

ESP with IPv6 extension headers

Supported

Supported

AH with IPv4 immutable options

Supported

Supported

AH with IPv6 immutable extension headers

Supported

Supported

AH with IPv4 mutable options

Not supported

Not supported

AH with IPv6 mutable extension headers

Not supported

Not supported

Integrity Check Value Calculation in IPv6

The AH protocol verifies the integrity of the IPv6 packet by computing an Integrity Check Value (ICV) on the packet contents. ICV is usually built over an authentication algorithm such as MD5 or SHA-1. The IPv6 ICV calculations differ from that in IPv4 in terms of two header fields—mutable header and optional extension header.

You can calculate the AH ICV over the IPv6 header fields that are either immutable in transit or predictable in value upon arrival at the tunnel endpoints. You can also calculate the AH ICV over the AH header and the upper level protocol data (considered to be immutable in transit). You can calculate the ESP ICV over the entire IPv6 packet, excluding the new outer IPv6 header and the optional extension headers.

Unlike IPv4, IPv6 has a method for tagging options as mutable in transit. IPv6 optional extension headers contain a flag that indicates mutability. This flag determines the appropriate processing.

IPv4 mutable options and IPv6 extension headers are not supported with the AH protocol.

Header Construction in Tunnel Modes

In tunnel mode, the source and destination addresses of the outer IPv4 or IPv6 header represent the tunnel endpoints, while the source and destination addresses of the inner IPv4 or IPv6 header represent the final source and destination addresses. Table 4 summarizes how the outer IPv6 header relates to the inner IPv6 or IPv4 header for IPv6-in-IPv6 or IPv4-in-IPv6 tunnel modes. In outer header fields, “Constructed” means that the value of the outer header field is constructed independently of the value in the inner header field.

Table 4: IPv6 Header Construction for IPv6-in-IPv6 and IPv4-in-IPv6 Tunnel Modes

Header Fields

Outer Header at Encapsulator

Inner Header at Decapsulator

version

6.

No change.

DS field

Copied from the inner header.

No change.

ECN field

Copied from the inner header.

Constructed.

flow label

0.

No change.

payload length

Constructed.

No change.

next header

AH, ESP, and routing header.

No change.

hop limit

64.

Decrement.

src address

Constructed.

No change.

dest address

Constructed.

No change.

Extension headers

Never copied.

No change.

Table 5 summarizes how the outer IPv4 header relates to the inner IPv6 or IPv4 header for IPv6-in-IPv4 or IPv4-in-IPv4 tunnel modes. In outer header fields, “Constructed” means that the value of the outer header field is constructed independently of the value in the inner header field.

Table 5: IPv4 Header Construction for IPv6-in-IPv4 and IPv4-in-IPv4 Tunnel Modes

Header Fields

Outer Header

Inner Header

version

4.

No change.

header length

Constructed.

No change.

DS field

Copied from the inner header.

No change.

ECN field

Copied from the inner header.

Constructed.

total length

Constructed.

No change.

ID

Constructed.

No change.

flags (DF, MF)

Constructed.

No change.

fragment offset

Constructed.

No change.

TTL

64.

Decrement.

protocol

AH, ESP

No change.

checksum

Constructed.

Constructed.

src address

Constructed.

No change.

dest address

Constructed.

No change.

options

Never copied.

No change.

For IPv6-in-IPv4 tunnel mode, the Don’t Fragment (DF) bit is cleared by default. If the df-bit set or df-bit copy options are configured at the [edit security ipsec vpn vpn-name] hierarchy level for the corresponding IPv4 VPN, the DF bit is set in the outer IPv4 header.

For IPv4-in-IPv4 tunnel mode, the DF bit in the outer IPv4 header is based on the df-bit option configured for the inner IPv4 header. If df-bit is not configured for the inner IPv4 header, the DF bit is cleared in the outer IPv4 header.

See Also

IPv6 IPsec Configuration Overview

Juniper Networks supports manual and autokey IKE with preshared keys configurations for IPv6 IPsec VPN.

  • AutoKey IKE VPN—In an autoKey IKE VPN configuration, the secret keys and SAs are automatically created using the autoKey IKE mechanism. To set up an IPv6 autoKey IKE VPN, two phases of negotiations are required—Phase 1 and Phase 2.

    • Phase 1—In this phase, the participants establish a secure channel for negotiating the IPsec SAs.

    • Phase 2—In this phase, the participants negotiate the IPsec SAs for authenticating and encrypting the IPv6 data packets.

    For more information on Phase 1 and Phase 2 negotiations, see Internet Key Exchange

See Also

Example: Configuring an IPv6 IPsec Manual VPN

This example shows how to configure an IPv6 IPsec manual VPN.

Requirements

Before you begin:

Overview

In a Manual VPN configuration, the secret keys are manually configured on the two IPsec endpoints.

In this example, you:

  • Configure the authentication parameters for a VPN named vpn-sunnyvale.

  • Configure the encryption parameters for vpn-sunnyvale.

  • Specify the outgoing interface for the SA.

  • Specify the IPv6 address of the peer.

  • Define the IPsec protocol. Select the ESP protocol because the configuration includes both authentication and encryption.

  • Configure a security parameter index (SPI).

Configuration

Procedure

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 algorithms:

  1. Configure the authentication parameters.

  2. Configure the encryption parameters.

  3. Specify the outgoing interface for the SA.

  4. Specify the IPv6 address of the peer.

  5. Define the IPsec protocol.

  6. Configure an SPI.

Results

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

Verification

To confirm that the configuration is working properly, perform this task:

Verifying Security Algorithms

Purpose

Determine if security algorithms are applied or not.

Action

From operational mode, enter the show security ipsec security-associations command.

See Also

Example: Configuring an IPv6 AutoKey IKE Policy-Based VPN

This example shows how to configure a policy-based IPv6 AutoKey IKE VPN to allow IPv6 data to be securely transferred between the branch office and the corporate office.

IPv6 policy-based VPNs are supported only on standalone SRX300, SRX320, SRX340, SRX345, and SRX550HM devices.

Requirements

This example uses the following hardware:

  • SRX300 device

Before you begin:

Overview

In this example, you configure an IPv6 IKE policy-based VPN for a branch office in Chicago, Illinois, because you do not need to conserve tunnel resources or configure many security policies to filter traffic through the tunnel. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

Figure 3 shows an example of an IPv6 IKE policy-based VPN topology. In this topology, one SRX Series Firewall is located in Sunnyvale, and another SRX Series Firewall (this can be a second SRX Series Firewall or a third-party device) is located in Chicago.

Figure 3: IPv6 IKE Policy-Based VPN TopologyIPv6 IKE Policy-Based VPN Topology

In this example, you configure interfaces, an IPv6 default route, security zones, and address books. Then you configure IKE Phase 1, IPsec Phase 2, a security policy, and TCP-MSS parameters. See Table 6 through Table 10.

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

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/14.0

2001:db8:3::1/96
 

ge-0/0/15.0

2001:db8:0:2::1/96

Security zones

Trust

  • All system services are allowed.

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

Untrust

  • IKE is the only allowed system service.

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

Address book entries

Sunnyvale

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

  • The address for this address book entry is 2001:db8:3::2/96.
 

Chicago

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

  • The address for this address book entry is 2001:db8:0::2/96.
Table 7: IPv6 IKE Phase 1 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ipv6-ike-phase1-proposal

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: aes-128-cbc

Policy

ipv6-ike-phase1-policy

  • Mode: Aggressive

  • Proposal reference: ipv6-ike-phase1-proposal

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

Gateway

gw-Chicago

  • IKE policy reference: ipv6-ike-phase1-policy

  • External interface: ge-0/0/15.0

  • Gateway address: 2001:db8:1::1/96
Table 8: IPv6 IPsec Phase 2 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ipv6-ipsec-phase2-proposal

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: aes-128-cbc

Policy

ipv6-ipsec-phase2-policy

  • Proposal reference: ipv6-ipsec-phase2-proposal

  • PFS: Diffie-Hellman group2

VPN

ipv6-ike-vpn-chicago

  • IKE gateway reference: gw-chicago

  • IPsec policy reference: ipv6-ipsec-phase2-policy
Table 9: Security Policy Configuration Parameters

Purpose

Name

Configuration Parameters

This security policy permits traffic from the Trust zone to the Untrust zone.

ipv6-vpn-tr-untr

  • Match criteria:

    • source-address Sunnyvale

    • destination-address Chicago

    • application any

  • Permit action: tunnel ipsec-vpn ipv6-ike-vpn-chicago

  • Permit action: tunnel pair-policy ipv6-vpn-untr-tr

This security policy permits traffic from the Untrust zone to the Trust zone.

ipv6-vpn-untr-tr

  • Match criteria:

    • source-address Chicago

    • destination-address Sunnyvale

    • application any

  • Permit action: tunnel ipsec-vpn ipv6-ike-vpn-chicago

  • Permit action: tunnel pair-policy ipv6-vpn-tr-untr

This security policy permits all traffic from the Trust zone to the Untrust zone.

You must put the ipv6-vpn-tr-untr policy before the permit-any security policy. Junos OS performs a security policy lookup starting at the top of the list. If the permit-any policy comes before the ipv6-vpn-tr-untr policy, all traffic from the Trust zone will match the permit-any policy and be permitted. Thus, no traffic will ever match the ipv6-vpn-tr-untr policy.

permit-any

  • Match criteria:

    • source-address any

    • source-destination any

    • application any

  • Action: permit
Table 10: TCP-MSS Configuration Parameters

Purpose

Configuration Parameters

TCP-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. This is especially important for VPN traffic, as 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, thus causing fragmentation. Fragmentation results in increased use of bandwidth and device resources.

We recommend a value of 1350 as the 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

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:

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

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:

  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. Assign an IP address to the IKE Phase 1 gateway.

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

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:

  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.

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

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:

  1. Create the security policy to permit traffic from the Trust zone to the Untrust zone.

  2. Create the security policy to permit traffic from the Untrust zone to the Trust zone.

  3. Create the security policy to permit traffic from the Trust zone to the Untrust zone.

  4. Reorder the security policies so that the vpn-tr-untr security policy is placed above the permit-any security policy.

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

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:

  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.

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 Sunnyvale to a host in Chicago. For policy-based VPNs, a separate host must generate the traffic; traffic initiated from the SRX Series Firewall will not match the VPN policy. We recommend that the test traffic be from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate ping from 2001:db8:3::2/96 to 2001:db8:0::2/96.

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 security associations (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 index_number 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 are 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 5 detail command lists additional information about the security association with an index number of 5:

  • 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 2. 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 3597/unlim value indicates that the Phase 2 lifetime expires in 3597 seconds, and that no lifesize has been specified, which indicates that the lifetime 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 (up) or D (down) is listed.

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

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

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

    A proxy ID mismatch is one of the most common reasons for a Phase 2 failure. For policy-based VPNs, the proxy ID is derived from the security policy. The local and remote addresses are derived from the address book entries, and the service is derived from the application configured for the policy. If Phase 2 fails because of a proxy ID mismatch, you can use the policy to confirm which address book entries are configured. Verify that the addresses match the information being sent. Check the service to ensure that the ports match the information being sent.

    For some third-party vendors, the proxy ID must be manually entered to match.

See Also

Related Documentation