Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Policy-Based IPsec VPNs

 

A policy-based VPN is a configuration in which an IPsec VPN tunnel created between two end points is specified within the policy itself with a policy action for the transit traffic that meets the policy’s match criteria.

Understanding Policy-Based IPsec VPNs

For policy-based IPsec VPNs, a security policy specifies as its action the VPN tunnel to be used for transit traffic that meets the policy’s match criteria. A VPN is configured independent of a policy statement. The policy statement refers to the VPN by name to specify the traffic that is allowed access to the tunnel. For policy-based VPNs, each policy creates an individual IPsec security association (SA) with the remote peer, each of which counts as an individual VPN tunnel. For example, if a policy contains a group source address and a group destination address, whenever one of the users belonging to the address set attempts to communicate with any one of the hosts specified as the destination address, a new tunnel is negotiated and established. Because each tunnel requires its own negotiation process and separate pair of SAs, the use of policy-based IPsec VPNs can be more resource-intensive than route-based VPNs.

Examples of where policy-based VPNs can be used:

  • You are implementing a dial-up VPN.

  • Policy-based VPNs allow you to direct traffic based on firewall policies.

Note

We recommend that you use route-based VPN when you want to configure a VPN between multiple remote sites. Route-based VPNs can provide the same capabilities as policy-based VPNs.

Example: Configuring a Policy-Based VPN

This example shows how to configure a policy-based IPsec VPN 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 do not need to conserve tunnel resources or configure many security policies to filter traffic through the tunnel. Users in the Chicago office will use the VPN to connect to their corporate headquarters in Sunnyvale, California.

Figure 1 shows an example of a policy-based VPN topology. In this topology, the SRX Series device is located in Sunnyvale, and an SSG Series device (or it can be another third-party device) is located in Chicago.

Figure 1: Policy-Based VPN Topology
Policy-Based VPN Topology

IKE IPsec tunnel negotiation occurs in two phases. In Phase 1, participants establish a secure channel in which to negotiate the IPsec security association (SA). In Phase 2, participants negotiate the IPsec SA for authenticating traffic that will flow through the tunnel. Just as there are two phases to tunnel negotiation, there are two phases to tunnel configuration.

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.

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

Feature

Name

Configuration Parameters

Interfaces

ge-0/0/0.0

192.168.10.1/24

 

ge-0/0/3.0

10.1.1.2/30

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.

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 192.168.10.0/24.

 

chicago

  • This address is an entry in the address book book2, which is attached to a zone called untrust.

  • 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: 10.1.1.1

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

Table 4: Security Policy Configuration Parameters

Purpose

Name

Configuration Parameters

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

vpn-tr-untr

  • Match criteria:

    • source-address sunnyvale

    • destination-address chicago

    • application any

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

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

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

vpn-untr-tr

  • Match criteria:

    • source-address chicago

    • destination-address sunnyvale

    • application any

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

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

This security policy permits all traffic from the trust zone to the untrust zone.

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

permit-any

  • Match criteria:

    • source-address any

    • source-destination any

    • 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 maximum transmission unit (MTU) limits on a network. This is especially important for VPN traffic, as the IPsec encapsulation overhead, along with the IP and frame overhead, can cause the resulting Encapsulating Security Payload (ESP) packet to exceed the MTU of the physical interface, thus causing fragmentation. Fragmentation results in increased use of 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 Basic Network, Security Zone, and Address Book Information

CLI Quick Configuration

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

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure basic network, security zone, and address book information:

  1. Configure Ethernet interface information.
  2. Configure static route information.
  3. Configure the untrust security zone.
  4. Assign an interface to the security zone.
  5. Specify allowed system services for the security zone.
  6. Configure the trust security zone.
  7. Assign an interface to the security zone.
  8. Specify allowed system services for the security zone.
  9. Create an address book and attach it to a zone.
  10. Create another address book and attach it to a zone.

Results

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

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

Configuring IKE

CLI Quick Configuration

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

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IKE:

  1. Create the IKE Phase 1 proposal.
  2. Define the IKE proposal authentication method.
  3. Define the IKE proposal Diffie-Hellman group.
  4. Define the IKE proposal authentication algorithm.
  5. Define the IKE proposal encryption algorithm.
  6. Create an IKE Phase 1 policy.
  7. Set the IKE Phase 1 policy mode.
  8. Specify a reference to the IKE proposal.
  9. Define the IKE Phase 1 policy authentication method.
  10. Create an IKE Phase 1 gateway and define its external interface.
  11. Define the IKE Phase 1 policy reference.

Results

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

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

Configuring IPsec

CLI Quick Configuration

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

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure IPsec:

  1. Create an IPsec Phase 2 proposal.
  2. Specify the IPsec Phase 2 proposal protocol.
  3. Specify the IPsec Phase 2 proposal authentication algorithm.
  4. Specify the IPsec Phase 2 proposal encryption algorithm.
  5. Create the IPsec Phase 2 policy.
  6. Specify the IPsec Phase 2 proposal reference.
  7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
  8. Specify the IKE gateway.
  9. Specify the IPsec Phase 2 policy.

Results

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

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

Configuring Security Policies

CLI Quick Configuration

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

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure security policies:

  1. Create the security policy to permit traffic from the trust zone to the untrust zone.
  2. Create the security policy to permit traffic from the untrust zone to the trust zone.
  3. Create the security policy to permit traffic from the trust zone to the untrust zone.
  4. Reorder the security policies so that the vpn-tr-untr security policy is placed above the permit-any security policy.

Results

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

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

Configuring TCP-MSS

CLI Quick Configuration

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

Step-by-Step Procedure

To configure TCP-MSS information:

  1. Configure TCP-MSS information.

Results

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

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

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

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

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 192.168.10/24 network to a host in the 192.168.168/24 network. For policy-based VPNs, a separate host must generate the traffic; traffic initiated from the SRX Series device will not match the VPN policy. We recommend that the test traffic be from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate ping from 192.168.10.10 to 192.168.168.10.

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

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

Meaning

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

If SAs are listed, review the following information:

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

  • Initiator and responder role information

    Note

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

  • Number of IPsec SAs created

  • Number of Phase 2 negotiations in progress

Verifying the IPsec Phase 2 Status

Purpose

Verify the IPsec Phase 2 status.

Action

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

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

Meaning

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

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

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

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

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

The output from the show security ipsec security-associations index 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 reasons for a Phase 2 failure. For policy-based VPNs, the proxy ID is derived from the security policy. The local address and remote address are derived from the address book entries, and the service is derived from the application configured for the policy. If Phase 2 fails because of a proxy ID mismatch, you can use the policy to confirm which address book entries are configured. Verify that the addresses match the information being sent. Check the service to ensure that the ports match the information being sent.

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 2

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 if the other error counters are incrementing.