Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

NAT-T is enabled by default therefore you must use the no-nat-traversal statement at the [edit security ike gateway gateway-name hierarchy level for disabling the NAT-T.

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

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

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

Requirements

Before you begin, read IPsec Overview.

Overview

In this example, you configure a route-based VPN. Host1 will use the VPN to connect to their corporate headquarters on SRX2.

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 DeviceRoute-Based VPN Topology with Only the Responder behind a NAT Device

In this example, you configure interfaces, IPsec, and security policies for both an initiator in SRX1 and a responder in SRX2. Then you configure IKE Phase 1 and IPsec Phase 2 parameters.

SRX1 sends packets with the destination address of 172.16.21.1 to establish the VPN. The NAT device translates the destination address to 10.1.31.1.

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

Table 1: Interface, Routing Options, and Security Parameters for SRX1

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/1

172.16.11.1/24

 

ge-0/0/0

10.1.11.1/24

 

st0.0 (tunnel interface)

10.1.100.1/24

Static routes

10.1.21.0/24

The next hop is st0.0.

 

172.16.21.1/32

The next hop is 172.16.11.2.

Security zones

untrust

  • The system services of IKE and ping.

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

 

trust

  • Allow all system services.

  • Allow all protocols.

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

Security policies

to-SRX2

Permit traffic from 10.1.11.0/24 in the trust zone to 10.1.21.0/24 in the untrust zone.

from-SRX2

Permit traffic from 10.1.21.0/24 in the untrust zone to 10.1.11.0/24 in the trust zone.

Table 2: IKE Phase 1 Configuration Parameters for SRX1

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

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

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

Table 3: IPsec Phase 2 Configuration Parameters for SRX1

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

  • 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, and Security Parameters for SRX2

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/1

10.1.31.1/24

 

ge-0/0/0

10.1.21.1/24

 

st0.0 (tunnel interface)

10.1.100.2/24

Static routes

172.16.11.1/32

The next hop is 10.1.31.2.

 

10.1.11.0/24

The next hop is st0.0.

Security zones

untrust

  • Allow IKE and ping system services.

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

 

trust

  • Allow all system services.

    Allow all protocols.

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

Security policies

to-SRX1

Permit traffic from 10.1.21.0/24 in the trust zone to 10.1.11.0/24 in the untrust zone.

from-SRX1

Permit traffic from 10.1.11.0/24 in the untrust zone to 10.1.21.0/24 in the trust zone.

Table 5: IKE Phase 1 Configuration Parameters for SRX2

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

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

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

Table 6: IPsec Phase 2 Configuration Parameters for SRX2

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

  • Establish tunnels immediately

Configuration

Configuring Interface, Routing Options, and Security Parameters for SRX1

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

  1. Configure the interfaces connected to the Internet, Host1, and the interface used for the VPN.

  2. Configure static routes for the traffic that will use the VPN and for SRX1 to reach the NAT device.

  3. Configure the untrust security zone.

  4. Configure the trust security zone.

  5. Configure address books for the networks used in the security policies.

  6. Create security policies to allow traffic between the hosts.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, and show security 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 SRX1

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 an IKE Phase 1 proposal.

  2. Create an IKE Phase 1 policy.

  3. Configure the IKE Phase 1 gateway parameters. The gateway address should be the IP for the NAT device.

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 SRX1

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. Create the IPsec Phase 2 policy.

  3. Configure the IPsec VPN parameters.

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, and Security Parameters for SRX2

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

  1. Configure the interfaces connected to the Internet, Host2, and the interface used for the VPN.

  2. Configure static routes for the traffic that will use the VPN and for SRX2 to reach SRX1.

  3. Configure the untrust security zone.

  4. Configure the trust security zone.

  5. Configure address books for the networks used in the security policies.

  6. Create security policies to allow traffic between the hosts.

Results

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, and show security 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 SRX2

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 an IKE Phase 1 proposal.

  2. Create an IKE Phase 1 policy.

  3. Configure the IKE Phase 1 gateway parameters. The gateway address should be the IP for SRX1.

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 SRX2

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. Create the IPsec Phase 2 policy.

  3. Configure the IPsec VPN parameters.

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.

Configuration for the NAT Device

CLI Quick Configuration

Static NAT is used in the example. Static NAT is bidirectional which means that traffic from 10.1.31.1 to 172.16.11.1 will also use the same NAT 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.

Verification

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

Verifying the IKE Phase 1 Status on SRX1

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode, enter the show security ike security-associations command. For a more detailed output, use the show security ike security-associations detail command.

Meaning

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

If SAs are listed, review the following information:

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

  • Remote address—Verify that the remote IP address is correct and that port 4500 is being used for peer-to-peer communication. Remember that NAT-T encapsulates both IKE and ESP traffic within UDP with port 4500.

  • Role initiator state

    • Up—The Phase 1 SA is established.

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

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

    • 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

    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 on SRX1

Purpose

Verify the IPsec status.

Action

From operational mode, enter the show security ipsec security-associations command. For a more detailed output, use the show security ipsec security-associations detail command.

Meaning

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

  • The remote gateway has an address of 172.16.21.1.

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

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

Purpose

Verify the IKE Phase 1 status.

Action

From operational mode, enter the show security ike security-associations command. For a more detailed output, use the show security ike security-associations detail command.

Meaning

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

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations 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 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

    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 on SRX2

Purpose

Verify the IPsec status.

Action

From operational mode, enter the show security ipsec security-associations command. For a more detailed output, use the show security ipsec security-associations detail command.

Meaning

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

  • The remote gateway has an ip address of 172.16.11.1.

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

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

Verifying Host-to-Host Reachability

Purpose

Verify Host1 can reach Host2.

Action

From Host1 ping Host2. To verify the traffic is using the VPN, use the command show security ipsec statistics on SRX1. Clear the statistics by using the command clear security ipsec statistics before running the ping command.

Meaning

The outputs show Host1 can ping Host2 and that the traffic is using the VPN.

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 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 static NAT device.

Figure 2: Policy-Based VPN Topology with Both an Initiator and a Responder Behind a NAT DevicePolicy-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 static 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/0

12.168.99.100/24

 

ge-0/0/1

10.1.99.1/24

Static routes

10.2.99.0/24 (default route)

The next hop is 12.168.99.100.

 

1.1.100.0/24

12.168.99.100

Security zones

trust

  • All system services are allowed.

  • All protocols are allowed.

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

 

untrust

  • The ge-0/0/0.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:

    • 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/0

13.168.11.100/24

 

ge-0/0/1

10.2.99.1/24

Static routes

10.1.99.0/24 (default route)

The next hop is 13.168.11.100

 

1.1.100.0/24

13.168.11.100

Security zones

trust

  • All system services are allowed.

  • All protocols are allowed.

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

 

untrust

  • The ge-0/0/0.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/1.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

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:

    • 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. Assign an interface to 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.

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

  1. Configure interfaces.

  2. Configure zones.

  3. Configure NAT.

  4. Configure the default security policy.

  5. Configure the routing option.

Results

From configuration mode, confirm your configuration by entering the show security nat 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. Assign an interface to the untrust security zone.

  4. Configure the trust security zone.

  5. Assign an interface to the trust security zone.

  6. 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. Define the IKE proposal authentication method.

  2. Define the IKE proposal Diffie-Hellman group.

  3. Define the IKE proposal authentication algorithm.

  4. Define the IKE proposal encryption algorithm.

  5. Create an IKE Phase 1 policy.

  6. Set the IKE Phase 1 policy mode.

  7. Specify a reference to the IKE proposal.

  8. Define the IKE Phase 1 policy authentication method.

  9. Create an IKE Phase 1 gateway and define its dynamic host name.

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

  11. Define the IKE Phase 1 policy reference.

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. Set IPsec Phase 2 to use perfect forward secrecy (PFS) group1.

  7. Specify the IPsec Phase 2 proposal reference.

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

Configuring NAT 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 the responder providing NAT:

  1. Configure interfaces.

  2. Configure zones.

  3. Configure NAT.

  4. Configure the default security policy.

  5. Configure the routing option.

Results

From configuration mode, confirm your configuration by entering the show security nat 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

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

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

    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.

Meaning

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

  • The remote gateway has a NAT address of 13.168.11.100.

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

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

    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.

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 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 Firewalls configured in a chassis cluster

  • One SRX Series Firewall providing NAT

  • One SRX Series Firewall 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 VPNNAT-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.

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.

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.

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.

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

    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.

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.

Change History Table

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

Release
Description
12.1X46-D10
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.