Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Example: Configuring a Route-Based VPN

This example shows how to configure a route-based IPsec VPN to allow data to be securely transferred between a branch office and the corporate office.

Requirements

This example uses the following hardware:

  • SRX240 device
  • SSG140 device

Before you begin, read 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 route-based VPN topology. In this topology, the SRX Series device is located in Sunnyvale, and an SSG Series device (or a third-party device) is located in Chicago.

Figure 1: Route-Based VPN Topology

 Route-Based VPN Topology

In this example, you configure interfaces, an IPv4 default route, security zones, and address books. Then you configure IKE Phase 1, IPsec Phase 2, security policy, and TCP-MSS parameters. See Table 1 through Table 5 for specific configuration parameters used in this example.

Table 1: Interface, Static Route, Security Zone, and Address Book Information

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/0.0

10.10.10.1/24

 

ge-0/0/3.0

1.1.1.2/30

 

st0.0 (tunnel interface)

10.11.11.10/24

Static routes

0.0.0.0/0 (default route)

The next hop is 1.1.1.1.

 

192.168.168.0/24

The next hop is st0.0.

Security zones

trust

  • All system services are allowed.
  • The ge-0/0/0.0 interface is bound to this zone.
 

untrust

  • IKE is the only allowed system service.
  • The ge-0/0/3.0 interface is bound to this zone.
 

vpn-chicago

The st0.0 interface is bound to this zone.

Address book entries

sunnyvale

  • This address is an entry in the address book book1, which is attached to a zone called trust.
  • The address for this address book entry is 10.10.10.0/24.
 

chicago

  • This address is an entry in the address book book2, which is attached to a zone called vpn-chicago.
  • The address for this address book entry is 192.168.168.0/24.

Table 2: IKE Phase 1 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ike-phase1-proposal

  • Authentication method: pre-shared-keys
  • Diffie-Hellman group: group2
  • Authentication algorithm: sha1
  • Encryption algorithm: aes-128-cbc

Policy

ike-phase1-policy

  • Mode: main
  • Proposal reference: ike-phase1-proposal
  • IKE Phase 1 policy authentication method: pre-shared-key ascii-text

Gateway

gw-chicago

  • IKE policy reference: ike-phase1-policy
  • External interface: ge-0/0/3.0
  • Gateway address: 2.2.2.2

Table 3: IPsec Phase 2 Configuration Parameters

Feature

Name

Configuration Parameters

Proposal

ipsec-phase2-proposal

  • Protocol: esp
  • Authentication algorithm: hmac-sha1-96
  • Encryption algorithm: aes-128-cbc

Policy

ipsec-phase2-policy

  • Proposal reference: ipsec-phase2-proposal
  • PFS: Diffie-Hellman group2

VPN

ike-vpn-chicago

  • IKE gateway reference: gw-chicago
  • IPsec policy reference: ipsec-phase2-policy
  • Bind to interface: st0.0

Table 4: Security Policy Configuration Parameters

Purpose

Name

Configuration Parameters

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

vpn-tr-chi

  • Match criteria:
    • source-address sunnyvale
    • destination-address chicago
    • application any
  • Action: permit

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

vpn-chi-tr

  • Match criteria:
    • source-address chicago
    • destination-address sunnyvale
    • application any
  • Action: permit

Table 5: TCP-MSS Configuration Parameters

Purpose

Configuration Parameters

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

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

MSS value: 1350

Configuration

Configuring Interface, Static Route, Security Zone, and Address Book Information

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30set interfaces st0 unit 0 family inet address 10.11.11.10/24 set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1set routing-options static route 192.168.168.0/24 next-hop st0.0set security zones security-zone untrust interfaces ge-0/0/3.0set security zones security-zone untrust host-inbound-traffic system-services ike set security zones security-zone trust interfaces ge-0/0/0.0set security zones security-zone trust host-inbound-traffic system-services all set security zones security-zone vpn-chicago interfaces st0.0set security address-book book1 address sunnyvale 10.10.10.0/24 set security address-book book1 attach zone trust set security address-book book2 address chicago 192.168.168.0/24 set security address-book book2 attach zone vpn-chicago

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.

To configure interface, static route, security zone, and address book information:

  1. Configure Ethernet interface information.
    [edit]user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24user@host# set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30user@host# set interfaces st0 unit 0 family inet address 10.11.11.10/24
  2. Configure static route information.
    [edit]user@host# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1user@host# set routing-options static route 192.168.168.0/24 next-hop st0.0
  3. Configure the untrust security zone.
    [edit ]user@host# edit security zones security-zone untrust
  4. Assign an interface to the security zone.
    [edit security zones security-zone untrust]user@host# set interfaces ge-0/0/3.0
  5. Specify allowed system services for the security zone.
    [edit security zones security-zone untrust]user@host# set host-inbound-traffic system-services ike
  6. Configure the trust security zone.
    [edit]user@host# edit security zones security-zone trust
  7. Assign an interface to the trust security zone.
    [edit security zones security-zone trust]user@host# set interfaces ge-0/0/0.0
  8. Specify allowed system services for the trust security zone.
    [edit security zones security-zone trust]user@host# set host-inbound-traffic system-services all
  9. Configure an address book and attach a zone to it.
    [edit security address-book book1]user@host# set address sunnyvale 10.10.10.0/24 user@host# set attach zone trust
  10. Configure the vpn-chicago security zone.
    [edit]user@host# edit security zones security-zone vpn-chicago
  11. Assign an interface to the security zone.
    [edit security zones security-zone vpn-chicago]user@host# set interfaces st0.0
  12. Configure another address book and attach a zone to it.
    [edit security address-book book2]user@host# set address chicago 192.168.168.0/24user@host# set attach zone vpn-chicago

Results

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

[edit]user@host# show interfaces
ge-0/0/0 {unit 0 {family inet {address 10.10.10.1/24;}}}
ge-0/0/3 {unit 0 {family inet {address 1.1.1.2/30 }}}
st0{unit 0 {family inet {address 10.11.11.10/24}}}
[edit]user@host# show routing-options
static {route 0.0.0.0/0 next-hop 1.1.1.1;route 192.168.168.0/24 next-hop st0.0;}
[edit]user@host# show security zones
security-zone untrust {host-inbound-traffic {system-services {ike;}}interfaces {ge-0/0/3.0;}}
security-zone trust {host-inbound-traffic {system-services {all;}}interfaces {ge-0/0/0.0;}}
security-zone vpn-chicago {interfaces {st0.0;}}
[edit]user@host# show security address-book
book1 {address sunnyvale 10.10.10.0/24;attach {zone trust;}}book2 {address chicago 192.168.168.0/24;attach {zone vpn-chicago;}}

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

Configuring IKE

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

set security ike proposal ike-phase1-proposal authentication-method pre-shared-keysset security ike proposal ike-phase1-proposal dh-group group2 set security ike proposal ike-phase1-proposal authentication-algorithm sha1 set security ike proposal ike-phase1-proposal encryption-algorithm aes-128-cbc set security ike policy ike-phase1-policy mode main set security ike policy ike-phase1-policy proposals ike-phase1-proposal set security ike policy ike-phase1-policy pre-shared-key ascii-text $ABC123 set security ike gateway gw-chicago external-interface ge-0/0/3.0 set security ike gateway gw-chicago ike-policy ike-phase1-policy set security ike gateway gw-chicago address 2.2.2.2

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.

To configure IKE:

  1. Create the IKE Phase 1 proposal.
    [edit security ike]user@host# set proposal ike-phase1-proposal
  2. Define the IKE proposal authentication method.
    [edit security ike proposal ike-phase1-proposal]user@host# set authentication-method pre-shared-keys
  3. Define the IKE proposal Diffie-Hellman group.
    [edit security ike proposal ike-phase1-proposal]user@host# set dh-group group2
  4. Define the IKE proposal authentication algorithm.
    [edit security ike proposal ike-phase1-proposal]user@host# set authentication-algorithm sha1
  5. Define the IKE proposal encryption algorithm.
    [edit security ike proposal ike-phase1-proposal]user@host# set encryption-algorithm aes-128-cbc
  6. Create an IKE Phase 1 policy.
    [edit security ike]user@host# set policy ike-phase1-policy
  7. Set the IKE Phase 1 policy mode.
    [edit security ike policy ike-phase1-policy]user@host# set mode main
  8. Specify a reference to the IKE proposal.
    [edit security ike policy ike-phase1-policy]user@host# set proposals ike-phase1-proposal
  9. Define the IKE Phase 1 policy authentication method.
    [edit security ike policy ike-phase1-policy]user@host# set pre-shared-key ascii-text $ABC123
  10. Create an IKE Phase 1 gateway and define its external interface.
    [edit security ike]user@host# set gateway gw-chicago external-interface ge-0/0/3.0
  11. Define the IKE Phase 1 policy reference.
    [edit security ike gateway gw-chicago]user@host# set ike-policy ike-phase1-policy
  12. Define the IKE Phase 1 gateway address.
    [edit security ike gateway gw-chicago]user@host# set address 2.2.2.2

Results

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

[edit]user@host# show security ike
proposal ike-phase1-proposal {authentication-method pre-shared-keys;dh-group group2;authentication-algorithm sha1;encryption-algorithm aes-128-cbc;}
policy ike-phase1-policy {mode main;proposals ike-phase1-proposal;pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA}
gateway gw-chicago {ike-policy ike-phase1-policy;address 2.2.2.2;external-interface ge-0/0/3.0;}

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

Configuring IPsec

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

set security ipsec proposal ipsec-phase2-proposal protocol espset security ipsec proposal ipsec-phase2-proposal authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec-phase2-proposal encryption-algorithm aes-128-cbc set security ipsec policy ipsec-phase2-policy proposals ipsec-phase2-proposalset security ipsec policy ipsec-phase2-policy perfect-forward-secrecy keys group2set security ipsec vpn ike-vpn-chicago ike gateway gw-chicagoset security ipsec vpn ike-vpn-chicago ike ipsec-policy ipsec-phase2-policyset security ipsec vpn ike-vpn-chicago bind-interface st0.0

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.

To configure IPsec:

  1. Create an IPsec Phase 2 proposal.
    [edit]user@host# set security ipsec proposal ipsec-phase2-proposal
  2. Specify the IPsec Phase 2 proposal protocol.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set protocol esp
  3. Specify the IPsec Phase 2 proposal authentication algorithm.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set authentication-algorithm hmac-sha1-96
  4. Specify the IPsec Phase 2 proposal encryption algorithm.
    [edit security ipsec proposal ipsec-phase2-proposal]user@host# set encryption-algorithm aes-128-cbc
  5. Create the IPsec Phase 2 policy.
    [edit security ipsec]user@host# set policy ipsec-phase2-policy
  6. Specify the IPsec Phase 2 proposal reference.
    [edit security ipsec policy ipsec-phase2-policy]user@host# set proposals ipsec-phase2-proposal
  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
    [edit security ipsec policy ipsec-phase2-policy]user@host# set perfect-forward-secrecy keys group2
  8. Specify the IKE gateway.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago ike gateway gw-chicago
  9. Specify the IPsec Phase 2 policy.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago ike ipsec-policy ipsec-phase2-policy
  10. Specify the interface to bind.
    [edit security ipsec]user@host# set vpn ike-vpn-chicago bind-interface st0.0

Results

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

[edit]user@host# show security ipsec
proposal ipsec-phase2-proposal {protocol esp;authentication-algorithm hmac-sha1-96;encryption-algorithm aes-128-cbc;}
policy ipsec-phase2-policy {perfect-forward-secrecy {keys group2;}proposals ipsec-phase2-proposal;}
vpn ike-vpn-chicago {bind-interface st0.0;ike {gateway gw-chicago;ipsec-policy ipsec-phase2-policy;}}

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

Configuring Security Policies

CLI Quick Configuration

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match source-address sunnyvaleset security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match destination-address chicago set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi match application any set security policies from-zone trust to-zone vpn-chicago policy vpn-tr-chi then permit set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match source-address chicagoset security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match destination-address sunnyvale set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr match application any set security policies from-zone vpn-chicago to-zone trust policy vpn-chi-tr then permit

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.

To configure security policies:

  1. Create the security policy to permit traffic from the trust zone to the vpn-chicago zone.
    [edit security policies from-zone trust to-zone vpn-chicago]user@host# set policy vpn-tr-chi match source-address sunnyvaleuser@host# set policy vpn-tr-chi match destination-address chicagouser@host# set policy vpn-tr-chi match application anyuser@host# set policy vpn-tr-chi then permit
  2. Create the security policy to permit traffic from the vpn-chicago zone to the trust zone.
    [edit security policies from-zone vpn-chicago to-zone trust]user@host# set policy vpn-chi-tr match source-address chicagouser@host# set policy vpn-chi-tr match destination-address sunnyvaleuser@host# set policy vpn-chi-tr match application anyuser@host# set policy vpn-chi-tr then permit

Results

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

[edit]user@host# show security policies
from-zone trust to-zone vpn-chicago {policy vpn-tr-vpn {match {source-address sunnyvale; destination-address chicago;application any;}then {permit;}}}
from-zone vpn-chicago to-zone trust {policy vpn-tr-vpn {match {source-address chicago;destination-address sunnyvale;application any;}then {permit;}}}

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

Configuring TCP-MSS

CLI Quick Configuration

To quickly configure this section of the example, copy the following command, paste it into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the command into the CLI at the [edit] hierarchy level.

set security flow tcp-mss ipsec-vpn mss 1350

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.

To configure TCP-MSS information:

  1. Configure TCP-MSS information.
    [edit]user@host# set security flow tcp-mss ipsec-vpn mss 1350

Results

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

[edit]user@host# show security flow
tcp-mss {ipsec-vpn {mss 1350;}}

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

Configuring the SSG Series Device

CLI Quick Configuration

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

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI.

set zone name vpn-chicagoset interface ethernet0/6 zone Trustset interface ethernet0/0 zone Untrustset interface tunnel.1 zone vpn-chicagoset interface ethernet0/6 ip 192.168.168.1/24set interface ethernet0/6 routeset interface ethernet0/0 ip 2.2.2.2/30set interface ethernet0/0 routeset interface tunnel.1 ip 10.11.11.11/24set flow tcp-mss 1350set address Trust “192.168.168-net” 192.168.168.0 255.255.255.0set address vpn-chicago "10.10.10-net" 10.10.10.0 255.255.255.0set ike gateway corp-ike address 1.1.1.2 Main outgoing-interface ethernet0/0 preshare 395psksecr3t sec-level standardset vpn corp-vpn gateway corp-ike replay tunnel idletime 0 sec-level standardset vpn corp-vpn monitor optimized rekeyset vpn corp-vpn bind interface tunnel.1set policy from Trust to Untrust “ANY” “ANY” “ANY” nat src permitset policy from Trust to vpn-chicago “192.168.168-net” “10.10.10-net” “ANY” permitset policy from vpn-chicago to Trust “10.10.10-net” “192.168.168-net” “ANY” permitset route 10.10.10.0/24 interface tunnel.1set route 0.0.0.0/0 interface ethernet0/0 gateway 2.2.2.1

Step-by-Step Procedure

Verification

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

Verifying the IKE Phase 1 Status

Purpose

Verify the IKE Phase 1 status.

Action

Note: Before starting the verification process, you need to send traffic from a host in the 10.10.10/24 network to a host in the 192.168.168/24 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 from 10.10.10.10 to 192.168.168.10.

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

user@host> show security ike security-associations
Index   Remote Address  State  Initiator cookie  Responder cookie  Mode
1       2.2.2.2         UP     744a594d957dd513  1e1307db82f58387  Main
user@host> show security ike security-associations index 1 detail
IKE peer 2.2.2.2, Index 1,
  Role: Responder, State: UP
  Initiator cookie: 744a594d957dd513, Responder cookie: 1e1307db82f58387
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 1.1.1.2:500, Remote: 2.2.2.2:500
  Lifetime: Expires in 28570 seconds
  Algorithms:
   Authentication        : sha1
   Encryption            : aes-cbc (128 bits)
   Pseudo random function: hmac-sha1
  Traffic statistics:
   Input bytes    :                 852
   Output bytes   :                 940
   Input packets  :                   5
   Output packets :                   5
  Flags: Caller notification sent
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

Meaning

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

If SAs are listed, review the following information:

  • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations index detail command to get more information about the SA.
  • Remote Address—Verify that the remote IP address is correct.
  • State
    • UP—The Phase 1 SA has been established.
    • DOWN—There was a problem establishing the Phase 1 SA.
  • Mode—Verify that the correct mode is being used.

Verify that the following are correct in your configuration:

  • External interfaces (the interface must be the one that receives IKE packets)
  • IKE policy parameters
  • Preshared key information
  • Phase 1 proposal parameters (must match on both peers)

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

  • Authentication and encryption algorithms used
  • Phase 1 lifetime
  • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)
  • 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 the IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

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

user@host> show security ipsec security-associations
  total configured sa: 2
  ID    Gateway          Port  Algorithm          SPI      Life:sec/kb  Mon vsys
  <16384 2.2.2.2         500   ESP:aes-128/sha1   76d64d1d 3363/ unlim   -   0
  >16384 2.2.2.2         500   ESP:aes-128/sha1   a1024ee2 3363/ unlim   -   0
user@host> show security ipsec security-associations index 16384 detail
  Virtual-system: Root
  Local Gateway: 1.1.1.2, Remote Gateway: 2.2.2.2
  Local Identity: ipv4_subnet(any:0,[0..7]=10.10.10.0/24)
  Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
    DF-bit: clear

    Direction: inbound, SPI: 1993755933, AUX-SPI: 0
    Hard lifetime: Expires in 3352 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2775 seconds
    Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)    
    Anti-replay service: enabled, Replay window size: 32

    Direction: outbound, SPI: 2701283042, AUX-SPI: 0
    Hard lifetime: Expires in 3352 seconds
    Lifesize Remaining: Unlimited
    Soft lifetime: Expires in 2775 seconds
    Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc
 (128 bits)    
    Anti-replay service: enabled, Replay window size: 32

Meaning

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

  • The ID number is 16384. Use this value with the show security ipsec security-associations index command to get more information about this particular SA.
  • There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-traversal uses port 4500 or another random high-number port.)
  • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3363/ unlim value indicates that the Phase 2 lifetime expires in 3363 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 16384 detail command lists the following information:

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

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

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

Reviewing Statistics and Errors for an IPsec Security Association

Purpose

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

Action

From operational mode, enter the show security ipsec statistics index index_number command, using the index number of the VPN for which you want to see statistics.

user@host> show security ipsec statistics index 16384
ESP Statistics:
  Encrypted bytes:              920
  Decrypted bytes:             6208
  Encrypted packets:              5
  Decrypted packets:             87
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

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

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

Meaning

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

Testing Traffic Flow Across the VPN

Purpose

Verify the traffic flow across the VPN.

Action

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

From operational mode, enter the ping command.

ssg-> ping 192.168.168.10 interface ge-0/0/0 count 5
PING 192.168.168.10 (192.168.168.10): 56 data bytes
64 bytes from 192.168.168.10: icmp_seq=0 ttl=127 time=8.287 ms
64 bytes from 192.168.168.10: icmp_seq=1 ttl=127 time=4.119 ms
64 bytes from 192.168.168.10: icmp_seq=2 ttl=127 time=5.399 ms
64 bytes from 192.168.168.10: icmp_seq=3 ttl=127 time=4.361 ms
64 bytes from 192.168.168.10: icmp_seq=4 ttl=127 time=5.137 ms

--- 192.168.168.10 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.119/5.461/8.287/1.490 ms

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

user@host> ping 10.10.10.10 from ethernet0/6
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 1 seconds from ethernet0/6
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=4/4/5 ms

Meaning

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

Modified: 2016-07-06