Route-Based and Policy-Based VPNs with NAT-T

 

Network Address Translation-Traversal (NAT-T) is a method used for managing IP address translation-related issues encountered when the data protected by IPsec passes through a device configured with NAT for address translation.

Understanding NAT-T

Network Address Translation-Traversal (NAT-T) is a method for getting around IP address translation issues encountered when data protected by IPsec passes through a NAT device for address translation. Any changes to the IP addressing, which is the function of NAT, causes IKE to discard packets. After detecting one or more NAT devices along the datapath during Phase 1 exchanges, NAT-T adds a layer of User Datagram Protocol (UDP) encapsulation to IPsec packets so they are not discarded after address translation. NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500 used as both the source and destination port. Because NAT devices age out stale UDP translations, keepalive messages are required between the peers.

There are two broad categories of NAT:

  • Static NAT, where there is a one-to-one relationship between the private and public addresses. Static NAT works in both inbound and outbound directions.

  • Dynamic NAT, where there is a many-to-one or many-to-many relationship between the private and public addresses. Dynamic NAT works in the outbound direction only.

The location of a NAT device can be such that:

  • Only the IKEv1 or IKEv2 initiator is behind a NAT device. Multiple initiators can be behind separate NAT devices. Initiators can also connect to the responder through multiple NAT devices.

  • Only the IKEv1 or IKEv2 responder is behind a NAT device.

  • Both the IKEv1 or IKEv2 initiator and the responder are behind a NAT device.

Dynamic endpoint VPN covers the situation where the initiator's IKE external address is not fixed and is therefore not known by the responder. This can occur when the initiator's address is dynamically assigned by an ISP or when the initiator's connection crosses a dynamic NAT device that allocates addresses from a dynamic address pool.

Configuration examples for NAT-T are provided for the topology in which only the responder is behind a NAT device and the topology in which both the initiator and responder are behind a NAT device. Site-to-site IKE gateway configuration for NAT-T is supported on both the initiator and responder. A remote IKE ID is used to validate a peer’s local IKE ID during Phase 1 of IKE tunnel negotiation. Both the initiator and responder require a local-identity and a remote-identity setting.

On SRX5400, SRX5600, and SRX5800 devices, the IPsec NAT-T tunnel scaling and sustaining issues are as follows:

  • For a given private IP address, the NAT device should translate both 500 and 4500 private ports to the same public IP address.

  • The total number of tunnels from a given public translated IP cannot exceed 1000 tunnels.

Starting from Junos OS Release 19.2R1, PowerMode IPSec (PMI) for NAT-T is supported only on SRX5400, SRX5600, and SRX5800 devices equipped with SRX5K-SPC3 Services Processing Card (SPC), or with vSRX.

Example: Configuring a Route-Based VPN with Only the Responder Behind a NAT Device

This example shows how to configure a route-based VPN with a responder behind a NAT device to allow data to be securely transferred between a branch office and the corporate office.

Requirements

Before you begin, read IPsec VPN Overview.

Overview

In this example, you configure a route-based VPN for a branch office in Chicago, Illinois, because you want to conserve tunnel resources but still get granular restrictions on VPN traffic. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

Figure 1 shows an example of a topology for route-based VPN with only the responder behind a NAT device.

Figure 1: Route-Based VPN Topology with Only the Responder Behind a NAT Device
Route-Based VPN
Topology with Only the Responder Behind a NAT Device

In this example, you configure interfaces, routing options, security zones, and security policies for both an initiator in Chicago and a responder in Sunnyvale. Then you configure IKE Phase 1 and IPsec Phase 2 parameters.

Packets sent from the initiator with a destination address 1.1.1.1/32 are translated to the destination address 71.1.1.1/32 on the NAT device.

See Table 1 through Table 3 for specific configuration parameters used for the initiator in the examples.

Table 1: Interface, Routing Options, Zones, and Security Policies for the Initiator

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/1

1.0.0.1/24

 

ge-0/0/3

33.1.1.1/24

 

st0.1 (tunnel interface)

31.1.1.2/24

Static routes

32.1.1.0/24

The next hop is st0.1.

 

1.1.1.1/32

The next hop is 1.0.0.2.

Security zones

untrust

  • Only IKE system service is allowed.

  • The ge-0/0/1.0 and the st0.1 interfaces are bound to this zone.

 

trust

  • All system services are allowed.

  • All protocols are allowed.

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

Security policies

to-sunnyvale

Permit traffic from 33.1.1.1/24 in the trust zone to 32.1.1.1/24 in the untrust zone.

from-sunnyvale

Permit traffic from 32.1.1.1/24 in the untrust zone to 33.1.1.1/24 in the trust zone.

Table 2: IKE Phase 1 Configuration Parameters for the Initiator

Feature

Name

Configuration Parameters

Proposal

ike_prop

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: 3des-cbc

Policy

ike_pol

  • Mode: main

  • Proposal reference: ike_prop

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

Gateway

gw1

  • IKE policy reference: ike_pol

  • External interface: ge-0/0/1.0

  • Gateway address: 1.1.1.1

  • Local peer (initiator): branch_natt1@example.net

  • Remote peer (responder): responder_natt1@example.net

Table 3: IPsec Phase 2 Configuration Parameters for the Initiator

Feature

Name

Configuration Parameters

Proposal

ipsec_prop

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: 3des-cbc

Policy

ipsec_pol

  • Proposal reference: ipsec_prop

  • Perfect forward secrecy (PFS) keys: group2

VPN

vpn1

  • IKE gateway reference: gw1

  • IPsec policy reference: ipsec_pol

  • Bind to interface: st0.1

  • Establish tunnels immediately

See Table 4 through Table 6 for specific configuration parameters used for the responder in the examples.

Table 4: Interface, Routing Options, Zones, and Security Policies for the Responder

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/2

71.1.1.1/24

 

ge-0/0/3

32.1.1.1/24

 

st0.1 (tunnel interface)

31.1.1.1/24

Static routes

0.0.0.0/0 (default route)

The next hop is 71.1.1.2.

 

33.1.1.0/24

The next hop is st0.1.

Security zones

untrust

  • Only IKE system service is allowed.

  • The ge-0/0/2.0 and the st0.1 interfaces are bound to this zone.

 

trust

  • All system services are allowed.

    All protocols are allowed.

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

Security policies

to-chicago

Permit traffic from 32.1.1.1/24 in the trust zone to 33.1.1.1/24 in the untrust zone.

from-chicago

Permit traffic from 33.1.1.1/24 in the untrust zone to 32.1.1.1/24 in the trust zone.

Table 5: IKE Phase 1 Configuration Parameters for the Responder

Feature

Name

Configuration Parameters

Proposal

ike_prop

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: sha1

  • Encryption algorithm: 3des-cbc

Policy

ike_pol

  • Mode: main

  • Proposal reference: ike_prop

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

Gateway

gw1

  • IKE policy reference: ike_pol

  • External interface: ge-0/0/2.0

  • Gateway address: 1.0.0.1

  • Local peer (responder): responder_natt1@example.net

  • Remote peer (initiator): branch_natt1@example.net

Table 6: IPsec Phase 2 Configuration Parameters for the Responder

Feature

Name

Configuration Parameters

Proposal

ipsec_prop

  • Protocol: esp

  • Authentication algorithm: hmac-sha1-96

  • Encryption algorithm: 3des-cbc

Policy

ipsec_pol

  • Proposal reference: ipsec_prop

  • PFS keys: group2

VPN

vpn1

  • IKE gateway reference: gw1

  • IPsec policy reference: ipsec_pol

  • Bind to interface: st0.1

  • Establish tunnels immediately

Configuration

Configuring Interface, Routing Options, Security Zones, and Security Policies for the Initiator

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 interface, static route, security zone, and security policy information:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the untrust security zone.
  4. Assign interfaces 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. Configure address books.
  10. Create security policies.

Results

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

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

Configuring IKE for the Initiator

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. Define the IKE Phase 1 gateway address.
  13. Set local-identity of the local peer.
  14. Set remote-identity of the responder. This is the IKE identifier.
  15. Define the external interface.

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 instructions in this example to correct the configuration.

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

Configuring IPsec for the Initiator

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 IPsec Phase 2 to use perfect forward secrecy (PFS).
  7. Specify the IPsec Phase 2 proposal reference.
  8. Specify the IKE gateway.
  9. Specify the IPsec Phase 2 policy.
  10. Specify the interface to bind.
  11. Specify that the tunnel be brought up immediately without waiting for a verification packet to be sent.

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 instructions in this example to correct the configuration.

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

Configuring Interfaces, Routing Options, Security Zones, and Security Policies for the Responder

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 interface, static route, security zones, policies and gateways:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the untrust security zone.
  4. Assign interfaces 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. Configure address books.
  10. Create security policies.

Results

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

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

Configuring IKE for the Responder

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. Define the IKE Phase 1 gateway address.
  13. Set local-identity of the responder.
  14. Set remote-identity of the responder. This is the IKE identifier.

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 instructions in this example to correct the configuration.

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

Configuring IPsec for the Responder

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 IPsec Phase 2 to use perfect forward secrecy (PFS).
  7. Specify the IPsec Phase 2 proposal reference.
  8. Specify the IKE gateway.
  9. Specify the IPsec Phase 2 policy.
  10. Specify the interface to bind.
  11. Specify that the tunnel be brought up immediately without waiting for a verification packet to be sent.

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 instructions in this example to correct the configuration.

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 for the Initiator

Purpose

Verify the IKE Phase 1 status.

Action

Note

Before starting the verification process, you must send traffic from a host in the 33.1.1.0 network to a host in the 32.1.1.0 network. For route-based VPNs, traffic can be initiated by the SRX Series device through the tunnel. We recommend that when testing IPsec tunnels, test traffic be sent 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 operation from 33.1.1.2 to 32.1.1.2.

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.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

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 and that port 500 is being used for peer-to-peer communication.

  • Role initiator state

    • Up—The Phase 1 SA has been established.

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

    • Both peers in the IPsec SA pair are using port 500.

    • Peer IKE ID—Verify the remote address is correct.

    • Local identity and remote identity—Verify these are correct.

  • 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 command lists additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

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

  • Role information

    Note

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

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the Initiator

Purpose

Verify the IPsec 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.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

Meaning

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

  • The remote gateway has a NAT address of 1.1.1.1.

  • Both peers in the IPsec SA pair are using port 500.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 2532/ unlim value indicates that the Phase 2 lifetime expires in 2532 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.

Verifying the IKE Phase 1 Status for the Responder

Purpose

Verify the IKE Phase 1 status.

Action

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.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

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 and that port 500 is being used for peer-to-peer communication.

  • Role responder state

    • Up—The Phase 1 SA has been established.

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

    • Peer IKE ID—Verify the address is correct.

    • Local identity and remote identity—Verify these addresses are correct.

  • 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 command lists additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

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

  • Role information

    Note

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

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the Responder

Purpose

Verify the IPsec 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.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

Meaning

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

  • The remote gateway has an ip address of 1.0.0.1.

  • Both peers in the IPsec SA pair are using port 500.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3571/ unlim value indicates that the Phase 2 lifetime expires in 3571 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 index_iddetail 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.

Example: Configuring a Policy-Based VPN with Both an Initiator and a Responder Behind a NAT Device

This example shows how to configure a policy-based VPN with both an initiator and a responder behind a NAT device to allow data to be securely transferred between a branch office and the corporate office.

Requirements

Before you begin, read IPsec VPN Overview.

Overview

In this example, you configure a policy-based VPN for a branch office in Chicago, Illinois, because you want to conserve tunnel resources but still get granular restrictions on VPN traffic. Users in the branch office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

In this example, you configure interfaces, routing options, security zones, security policies for both an initiator and a responder.

Figure 2 shows an example of a topology for a VPN with both an initiator and a responder behind a NAT device.

Figure 2: Policy-Based VPN Topology with Both an Initiator and a Responder Behind a NAT Device
Policy-Based
VPN Topology with Both an Initiator and a Responder Behind a NAT Device

In this example, you configure interfaces, an IPv4 default route, and security zones. Then you configure IKE Phase 1, including local and remote peers, IPsec Phase 2, and the security policy. Note in the example above, the responder’s private IP address 13.168.11.1 is hidden by the NAT device and mapped to public IP address 1.1.100.1.

See Table 7 through Table 10 for specific configuration parameters used for the initiator in the examples.

Table 7: Interface, Routing Options, and Security Zones for the Initiator

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/1

12.168.99.100/24

 

ge-0/0/2

10.1.99.1/24

Static routes

10.2.99.0/24 (default route)

The next hop is 12.168.99.1.

 

13.168.11.0/24

The next hop is 12.168.99.1.

 

1.1.100.0/24

12.168.99.1

Security zones

trust

  • All system services are allowed.

  • All protocols are allowed.

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

 

untrust

  • All system services are allowed.

  • All protocols are allowed.

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

Table 8: IKE Phase 1 Configuration Parameters for the Initiator

Feature

Name

Configuration Parameters

Proposal

ike_prop

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: md5

  • Encryption algorithm: 3des-cbc

Policy

ike_pol

  • Mode: main

  • Proposal reference: ike_prop

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

Gateway

gate

  • IKE policy reference: ike_pol

  • External interface: ge-0/0/1.0

  • Gateway address: 1.1.100.23

  • Local peer is hostname chicago

  • Remote peer is hostname sunnyvale

Table 9: IPsec Phase 2 Configuration Parameters for the Initiator

Feature

Name

Configuration Parameters

Proposal

ipsec_prop

  • Protocol: esp

  • Authentication algorithm: hmac-md5-96

  • Encryption algorithm: 3des-cbc

Policy

ipsec_pol

  • Proposal reference: ipsec_prop

  • Perfect forward secrecy (PFS): group1

VPN

first_vpn

  • IKE gateway reference: gate

  • IPsec policy reference: ipsec_pol

Table 10: Security Policy Configuration Parameters for the Initiator

Purpose

Name

Configuration Parameters

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

pol1

  • Match criteria:

    • source-address any

    • destination-address any

    • application any

  • Action: permit tunnel ipsec-vpn first_vpn

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

pol1

  • Match criteria:

    • source-address any

    • destination-address any

    • application any

  • Action: permit tunnel ipsec-vpn first_vpn

See Table 11 through Table 14 for specific configuration parameters used for the responder in the examples.

Table 11: Interface, Routing Options, and Security Zones for the Responder

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/2

13.168.11.100/24

 

ge-0/0/3

10.2.99.1/24

Static routes

10.1.99.0/24 (default route)

The next hop is 13.168.11.1.

 

12.168.99.0/24

The next hop is 13.168.11.1.

 

1.1.100.0/24

13.168.11.1

Security zones

trust

  • All system services are allowed.

  • All protocols are allowed.

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

 

untrust

  • All system services are allowed.

  • All protocols are allowed.

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

Table 12: IKE Phase 1 Configuration Parameters for the Responder

Feature

Name

Configuration Parameters

Proposal

ike_prop

  • Authentication method: pre-shared-keys

  • Diffie-Hellman group: group2

  • Authentication algorithm: md5

  • Encryption algorithm: 3des-cbc

Policy

ike_pol

  • Mode: main

  • Proposal reference: ike_prop

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

Gateway

gate

  • IKE policy reference: ike_pol

  • External interface: ge-0/0/2.0

  • Gateway address: 1.1.100.22

  • Always send dead-peer detection

  • Local peer is hostname sunnyvale

  • Remote peer is hostname chicago

Table 13: IPsec Phase 2 Configuration Parameters for the Responder

Feature

Name

Configuration Parameters

Proposal

ipsec_prop

  • Protocol: esp

  • Authentication algorithm: hmac-md5-96

  • Encryption algorithm: 3des-cbc

Policy

ipsec_pol

  • Proposal reference: ipsec_prop

  • Perfect forward secrecy (PFS): group1

VPN

first_vpn

  • IKE gateway reference: gate

  • IPsec policy reference: ipsec_pol

  • Establish tunnels immediately

Table 14: Security Policy Configuration Parameters for the Responder

Purpose

Name

Configuration Parameters

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

pol1

  • Match criteria:

    • source-address any

    • destination-address any

    • application any

  • Action: permit tunnel ipsec-vpn first_vpn

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

pol1

  • Match criteria:

    • source-address any

    • destination-address any

    • application any

  • Action: permit tunnel ipsec-vpn first_vpn

Configuration

Configuring Interface, Routing Options, and Security Zones for the Initiator

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 interfaces, static routes, and security zones:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the trust security zone.
  4. Assign an interface to the trust security zone.
  5. Specify system services for the trust security zone.
  6. Configure the untrust security zone.
  7. Assign an interface to the untrust security zone.
  8. Specify system services for the untrust security zone.

Results

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

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

Configuring IKE for the Initiator

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. Create an IKE Phase 1 gateway address.
  12. Define the IKE Phase 1 policy reference.
  13. Set local-identity for the local peer.
  14. Set remote-identity for the responder. This is the responder’s local identity.

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 instructions in this example to correct the configuration.

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

Configuring IPsec for the Initiator

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. Specify the IPsec Phase 2 proposal reference.
  6. Specify IPsec Phase 2 to use perfect forward secrecy (PFS) group1.
  7. Specify the IKE gateway.
  8. 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 instructions in this example to correct the configuration.

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

Configuring Security Policies for the Initiator

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.

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 instructions in this example to correct the configuration.

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

Configuring Interface, Routing Options, and Security Zones for the Responder

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 interfaces, static routes, security zones, and security policies:

  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.

Results

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

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

Configuring IKE for the Responder

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. Create an IKE Phase 1 gateway address.
  13. Set local-identity for the local peer (initiator).
  14. Set remote-identity for the responder. This is the responder’s local identity.
  15. Set dead peer detection to detect whether the peer is up or down.

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 instructions in this example to correct the configuration.

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

Configuring IPsec for the Responder

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. Set IPsec Phase 2 to use perfect forward secrecy (PFS) group1.
  6. Create the IPsec Phase 2 policy.
  7. Specify the IPsec Phase 2 proposal reference.
  8. Specify the IKE gateway.
  9. Specify the IPsec Phase 2 policy.
  10. Specify that the tunnel be brought up immediately without a verification packet.

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 instructions in this example to correct the configuration.

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

Configuring Security Policies for the Responder

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.

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 instructions in this example to correct the configuration.

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 for the Initiator

Purpose

Verify the IKE Phase 1 status.

Action

Note

Before starting the verification process, you must send traffic from a host in the 10.1.99.0 network to a host in the 10.2.99.0 network. For route-based VPNs, traffic can be initiated by the SRX Series device through the tunnel. We recommend that when testing IPsec tunnels, test traffic be sent 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 operation from 10.1.99.2 to 10.2.99.2.

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.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

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 and that port 4500 is being used for peer-to-peer communication.

  • Role initiator state

    • Up—The Phase 1 SA has been established.

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

    • Both peers in the IPsec SA pair are using port 4500, which indicates that NAT-T is implemented. (NAT-T uses port 4500 or another random high-numbered port.)

    • Peer IKE ID—Verify the remote (responder) ID is correct. In this example, the hostname is sunnyvale.

    • Local identity and remote identity—Verify these are correct.

  • 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 command lists additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

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

  • Role information

    Note

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

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the Initiator

Purpose

Verify the IPsec 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.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

Meaning

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

  • The remote gateway has a NAT address of 1.1.100.23.

  • Both peers in the IPsec SA pair are using port 4500, which indicates that NAT-T is implemented. (NAT-T uses port 4500 or another random high-numbered port.).

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3390/ unlimited value indicates that the Phase 2 lifetime expires in 3390 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.

Verifying the IKE Phase 1 Status for the Responder

Purpose

Verify the IKE Phase 1 status.

Action

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.

user@host> show security ike security-associations
user@host> show security ike security-associations index 1 detail

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 and that port 4500 is being used for peer-to-peer communication.

  • Role responder state

    • Up—The Phase 1 SA has been established.

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

    • Peer IKE ID—Verify the local ID for the peer is correct. In this example, the hostname is chicago.

    • Local identity and remote identity—Verify these are correct.

  • 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 command lists additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

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

  • Role information

    Note

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

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the Responder

Purpose

Verify the IPsec 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.

user@host> show security ipsec security-associations
user@host> show security ipsec security-associations detail

Meaning

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

  • The remote gateway has a NAT address of 1.0.0.1.

  • Both peers in the IPsec SA pair are using port 4500, which indicates that NAT-T is implemented. (NAT-T uses port 4500 or another random high-numbered port.)

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3571/ unlim value indicates that the Phase 2 lifetime expires in 3571 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.

Example: Configuring NAT-T with Dynamic Endpoint VPN

This example shows how to configure a route-based VPN where the IKEv2 initiator is a dynamic endpoint behind a NAT device.

Requirements

This example uses the following hardware and software components:

  • Two SRX Series devices configured in a chassis cluster

  • One SRX Series device providing NAT

  • One SRX Series device providing branch office network access

  • Junos OS Release 12.1X46-D10 or later for IKEv2 NAT-T support

Overview

In this example, an IPsec VPN is configured between the branch office (IKEv2 initiator) and headquarters (IKEv2 responder) to secure network traffic between the two locations. The branch office is located behind the NAT device. The branch office address is assigned dynamically and is unknown to the responder. The initiator is configured with the remote identity of the responder for tunnel negotiation. This configuration establishes a dynamic endpoint VPN between the peers across the NAT device.

Figure 3 shows an example of a topology with NAT-Traversal (NAT-T) and dynamic endpoint VPN.

Figure 3: NAT-T with Dynamic Endpoint VPN
NAT-T with Dynamic Endpoint VPN

In this example, the initiator’s IP address, 192.179.100.50, which has been dynamically assigned to the device, is hidden by the NAT device and translated to 100.10.1.253.

The following configuration options apply in this example:

  • The local identity configured on the initiator must match the remote gateway identity configured on the responder.

  • Phase 1 and Phase 2 options must match between the initiator and responder.

Note

In this example, the default security policy that permits all traffic is used for all devices. More restrictive security policies should be configured for production environments. See Security Policies Overview.

Note

Starting with Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, the default value for the nat-keepalive option configured at the [edit security ike gateway gateway-name] hierarchy level has been changed from 5 seconds to 20 seconds.

Note

In SRX1400, SRX3400, SRX3600, SRX5600, and SRX5800 devices, IKE negotiations involving NAT traversal do not work if the IKE peer is behind a NAT device that will change the source IP address of the IKE packets during the negotiation. For example, if the NAT device is configured with DIP, it changes the source IP because the IKE protocol switches the UDP port from 500 to 4500. (Platform support depends on the Junos OS release in your installation.)

Configuration

Configuring the Branch Office Device (IKEv2 Initiator)

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 the branch office device:

  1. Configure interfaces.
  2. Configure routing options.
  3. Configure zones.
  4. Configure Phase 1 options.
  5. Configure Phase 2 options.
  6. Configure the security policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, show security zones, show security ike, show security ipsec, and show security policies 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 the NAT Device

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 the intermediate router providing NAT:

  1. Configure interfaces.
  2. Configure zones.
  3. Configure NAT.
  4. Configure the default security policy.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show security zones, show security nat source, and show security policies 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 the Headquarters Device (IKEv2 Responder)

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.

  1. Configure two nodes as the chassis cluster.
  2. Configure interfaces.
  3. Configure routing options.
  4. Configure zones.
  5. Configure Phase 1 options.
  6. Configure Phase 2 options.
  7. Configure the default security policy.

Results

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

Verification

Confirm that the configuration is working properly.

Verifying the IKE Phase 1 Status for the Responder

Purpose

Verify the IKE Phase 1 status.

Action

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

user@host# show security ike security-associations

user@host# show security ike security-associations detail

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 index_id detail command to get more information about the SA.

  • Remote address—Verify that the local IP address is correct and that port 4500 is being used for peer-to-peer communication.

  • Role responder state

    • Up—The Phase 1 SA has been established.

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

    • Peer IKE ID—Verify the address is correct.

    • Local identity and remote identity—Verify these addresses are correct.

  • 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 sends IKE packets)

  • IKE policy parameters

  • Preshared key information

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

The show security ike security-associations command lists additional information about security associations:

  • Authentication and encryption algorithms used

  • Phase 1 lifetime

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

  • Role information

    Note

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

  • Initiator and responder information

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying IPsec Security Associations for the Responder

Purpose

Verify the IPsec status.

Action

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

user@host# show security ipsec security-associations
user@host# show security ipsec security-associations detail

Meaning

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

  • The remote gateway has an IP address of 100.10.1.253.

  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The lifetime value indicates that the Phase 2 lifetime expires in 7186 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.

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

The output from the show security ipsec security-associations index index_id 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, match 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.

Release History Table
Release
Description
Starting with Junos OS Release 12.1X46-D10 and Junos OS Release 17.3R1, the default value for the nat-keepalive option configured at the [edit security ike gateway gateway-name] hierarchy level has been changed from 5 seconds to 20 seconds.