Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Configuring VPNs with Overlapping Subnets Using SRX Series Devices

 

This example shows how to configure and verify a Layer 3 virtual private networks (VPN) with overlapping subnets.

Note

Our content testing team has validated and updated this example.

Requirements

This example requires the following hardware and software components:

  • Junos OS Release 9.5 or later

    • Revalidated on Junos OS Release 19.3R1

  • Juniper Networks SRX Series Services Gateways

Overview

This example shows how to configure and verify a Layer 3 VPN with overlapping subnets.

Note
  • Configuration and troubleshooting details of route-based virtual private networks (VPNs) and other Junos OS-specific documents are available at the Juniper Networks Knowledge Base at https://kb.juniper.net .

  • For more information about VPN configuration and troubleshooting, see KB10182 (https://kb.juniper.net/KB10182) available at the Juniper Networks Knowledge Base.

Topology

Figure 1 shows the network topology used in this configuration example.

Figure 1: Network Topology
Network Topology

This example requires the following:

  • The internal LAN interface for both sites is ge-0/0/3 in zone trust and has 192.168.10.1/24 as the private IP address.

  • The Internet interface for both sites is ge-0/0/1 in zone untrust and each site has a unique public IP address.

  • The st0.0 secure tunnel interface is in zone vpn on both sites. This secure tunnel interface allows configuring a unique policies specifically for tunnel (encrypted) traffic while maintaining unique policies for clear (non-encrypted) traffic.

  • The address range to reach the Remote site hosts from the Corporate site is 10.1.1.2/24.

  • The address range to reach Corporate site hosts from the Remote site is 10.1.1.1/24.

  • All traffic between the Corporate and Remote LANs is permitted, and traffic might be initiated from either side.

  • Basic non-VPN settings such as system settings, user login, and default security settings are preconfigured on both devices.

Configuration

To configure a VPN with overlapping subnets involves the following steps:

Configuring the Basic Parameters on Corporate and Remote Sites

Step-by-Step Procedure

  1. Configure the IP addresses for the ge-0/0/1.0, ge-0/0/3.0, and st0.0 interfaces.
  2. Configure a default route to the Internet next hop and a static route for the remote office LAN.

    Optionally, you can use a dynamic routing protocol such as OSPF, but that is beyond the scope of this document.

  3. Configure a security zone and bind the interfaces to the appropriate zones.
  4. Enable the necessary host-inbound services on the interfaces or the zone.

    For this example, you must enable Internet Key Exchange (IKE) service on either the ge-0/0/1 interface or the untrust zone.

  5. Configure address book entries for each zone.

    This is necessary for the security policies.

  6. Configure the phase 1 (IKE) proposal.
  7. Configure an IKE policy referencing the phase 1 proposal.
  8. Configure an IKE gateway profile referencing the IKE policy.
  9. Configure a phase 2 (IPsec) proposal.
  10. Configure an IPsec policy referencing the phase 2 proposal
  11. Configure a VPN profile referencing the IPsec policy and the IKE gateway.
  12. Bind interface st0.0 to the VPN.

    This makes the VPN a route-based VPN.

  13. Configure source NAT settings for the st0 interface.
  14. Configure security policies to permit remote VPN traffic into the corporate LAN and vice versa.

Configuring the Corporate Site

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Configure IP addresses for the private LAN, Internet, and st0 interfaces.

    Junos OS uses the concept of units for the logical component of an interface. In this example, unit 0 and family inet (IPv4) are used. It is not mandatory for st0 interfaces on both sides to reside on the same IP address subnet, since the link is logically a point-to-point link.

  2. Configure a static default route to the Internet gateway, and a static route for the tunnel traffic.Note

    This example uses a direct connection between the corporate and remote sites. As a result there is no Internet Gateway next hop, which would be used to route traffic not intended for the remote VPN site. This example configures a default route to the remote VPN site to simulate the functionality of an Internet gateway. Because this is done at both sites, there is a potential for a packet loop if traffic is sent to nonexistent addresses. This does not affect the functionality of the example.

    Normally, for static routes, the gateway IP address is specified as the next hop. For route-based VPNs, specify the remote peer st0 interface IP address or just the local st0 interface as the next hop.

  3. Configure security zones, and assign interfaces to the zones.

    Creating a unique zone for tunnel traffic enables you to create a set of policies specifically for VPN traffic while maintaining separation of policies for non-VPN traffic. Also, you can create deny policies to exclude specific hosts to access the VPN.

    Note

    If you are terminating the st0 interface in the same zone as the trusted LAN and if a policy exists to allow intra-zone traffic on that zone, no additional security policies are required.

  4. Configure host-inbound services for each interface in the zones.

    Host-inbound services are for traffic destined for the Junos OS-based device. This includes but is not limited to FTP, HTTP, HTTPS, IKE, ping, rlogin, RSH, SNMP, SSH, Telnet, Trivial File Transfer Protocol (TFTP), and traceroute. This example assumes that you want to allow all such services from zone trust. For security reasons, only allow IKE on the Internet facing zone untrust, which is required for IKE negotiations to occur. Other services such as those for management, or troubleshooting, or both can also be individually enabled if required.

  5. Configure address book entries for each zone.

    This example uses address book object names local-net and remote-net to define the Corporate to Remote LAN segments. However, in order to permit all traffic from the reverse direction, the address book object needs to reflect the source NAT address range for st0.0. This is because the traffic egressing out from the Remote site to reach the Corporate site has a destination address of 10.1.1.1/24, not 192.168.10.10/24.

  6. Configure the IKE phase 1 proposal.

    This example uses a proposal that includes preshared keys, group2, triple Data Encryption Standard (3DES), and the sha1 algorithm. Define your proposal in accordance with your Corporate security policy.

  7. Configure the IKE policy.

    The IKE policy specifies main mode, which is most commonly used for site-to-site VPNs where both peers have static IP addresses. Aggressive mode is typically used when one peer is a dynamic peer. For both peers, the mode must match. In the IKE policy, both the phase 1 proposal and preshared key are defined.

  8. Configure the IKE gateway (phase 1) with the peer IP address and peer ID type.

    A remote IKE peer can be identified by either the IP address, the FQDN/u-FQDN, or the ASN1-DN (PKI certificates). This example identifies the peer by IP address. Therefore, the gateway address must be the remote peer’s public IP address. Also, it is important to specify the correct external interface. If either the peer address or external interface specified is incorrect, then the IKE gateway is not properly identified during phase 1 negotiations.

  9. Configure the IPsec phase 2 proposal.

    This example uses a proposal that includes Encapsulating Security Payload (ESP), 3DES encryption, the sha1 algorithm, and a lifetime of 3600 seconds (1 hour). Define your proposal in accordance with your Corporate security policy.

  10. Configure the IPsec policy.

    The VPN policy must specify a phase 2 proposal. Perfect-forward-secrecy is optional, though recommended for increased security.

  11. Configure an IPsec VPN with an IKE gateway and IPsec policy, and bind it to the st0 interface.

    Binding an st0 interface differentiates this VPN as a route-based VPN. For policy-based VPNs, you do not configure an st0 interface. If an st0 interface is not specified, phase 2 cannot complete negotiations if this is a route-based VPN.

  12. Configure static NAT for the st0 interface.
  13. Configure security policies for tunnel traffic in both directions.

    A security policy permits traffic in one direction, but also allows all reply traffic without the need for a reverse direction policy. However, since traffic can be initiated from either direction, bidirectional policies are required. Also, you can create more granular policies between zone vpn and zone trust and can permit or deny traffic accordingly. Note that the policies are regular non-tunnel policies. Therefore, the policies do not specify the IPsec profile. Although the static NAT policy is bidirectional, security policies are still required to actually permit the traffic in both directions.

  14. Configure a security policy for Internet traffic.

    A security policy is required to permit all traffic from zone trust to zone untrust.

Results

For reference, the configuration of the Corporate site router is shown.

Corporate Site Configuration

user@CORPORATE> show configuration | no-more

Configuring the Remote Site

Step-by-Step Procedure

Most of the Corporate site configuration applies to the Remote site as well. Therefore, the same information is not repeated in this example unless some specific details for the Remote site need to be pointed out. To begin, enter configuration mode using either the configure or edit command.

  1. Configure IP addresses for the private LAN, Internet, and st0 interfaces.
  2. Configure a static default route to the Internet gateway and a static route for the tunnel traffic.Note

    This example uses a direct connection between the corporate and remote sites. As a result there is no Internet gateway next hop, which would be used to route traffic not intended for the corporate VPN site. This example configures a default route to the corporate VPN site to simulate the functionality of an Internet gateway. Because this is done at both sites, there is a potential for a packet loop if traffic is sent to nonexistent addresses. This does not affect the functionality of the example.

  3. Configure security zones, and assign interfaces to the zones.
  4. Configure host-inbound services for each interface in the zones.
  5. Configure address book entries for each zone.
  6. Configure the IKE phase 1 proposal.
    Note

    The proposal must match the peer side exactly or phase 1 fails.

  7. Configure the IKE policy.
    Note

    Ensure that the preshared key matches exactly with the peer side.

  8. Configure the IKE gateway (phase 1) with the peer IP address and peer ID type.

    Since both peers have static IP addresses, you can use the IP address as the peer ID type.

  9. Configure an IPsec phase 2 proposal.
    Note

    The proposal must match the peer side exactly or phase 2 fails.

  10. Configure an IPsec policy.

    If the remote peer is configured for perfect-forward-secrecy, it must be configured in this step.

  11. Configure an IPsec VPN with an IKE gateway and IPsec policy, and bind it to the st0 interface.
  12. Configure static NAT.

    Similar to Corporate site settings, map the entire 10.0.20.10/24 subnet with the remote LAN 192.168.10.10/24 subnet. This is again a one-to-one mapping for each host on the subnet to the other. You do not need to perform any port translations in this instance.

  13. Configure security policies for tunnel traffic in both directions.
  14. Configure a security policy for Internet traffic.

Results

For reference, the configuration of the Remote site router is shown.

Remote Site Configuration

user@REMOTE> show configuration | no-more

Verification

Confirm that the configuration is working properly.

Verifying the VPN Connection — Confirm IKE (Phase 1) Status

Purpose

Confirm the VPN connection by checking the status of IKE phase 1 security associations.

Action

Use the following command from the Corporate site’s services router:

user@CORPORATE> show security ike security-associations

The output shows that the remote peer is 172.16.0.2, and the state shown is UP. If the state shown is DOWN or if there are no IKE security associations shown, then there is a problem with phase 1 establishment. Confirm that the remote IP address, IKE policy, and external interfaces are all correct. Common errors include incorrect IKE policy parameters such as wrong mode type (aggressive or main), pre-shared key, or phase 1 proposals (all parameters must match on both peers). An incorrect external interface is another common misconfiguration. This interface must be the interface that receives the IKE packets. If configurations are checked and are set correctly, then check the kmd log for any errors.

Note the index number in the output. The index number generated is 164226 in this example. This value is unique for each IKE security association and allows you to get more details from that particular security association (SA) as shown here:

user@CORPORATE> show security ike security-associations index 164226 detail

The detail option provides more information, including the role (initiator or responder). This is useful to know because troubleshooting is always best done on the peer that has the responder role. Also shown are details regarding the authentication and encryption algorithms used, the phase 1 lifetime, and traffic statistics. Traffic statistics can be used to verify that traffic is flowing properly in both directions. Finally, note the number of IPsec security associations created or in progress. This can help to determine the existence of any completed phase 2 negotiations.

Verifying the VPN Connection — Confirm IPsec (Phase 2) Status

Purpose

Confirm that IPsec (phase 2) is connected.

Action

Once IKE phase 1 is confirmed, run the show security ipsec security-associations command to view IPsec (phase 2) SAs.

user@CORPORATE> show security ipsec security-associations

In this output, there is one IPsec SA pair, and the port used is 500, which means there is no NAT traversal (nat-traversal would show port 4500 or random high port). Also, you can see the security parameter index (SPI) used for both directions, as well as the lifetime (in seconds) and usage limits or lifesize (in kilobytes). 3121/ unlim means that the phase 2 lifetime is set to expire in 3121 seconds, and because no lifesize is specified, it displays as unlim. Phase 2 lifetime can differ from phase 1 lifetime, since phase 2 is not dependent on phase 1 once the VPN is up. The Mon column refers to VPN monitoring status. When VPN monitoring is enabled, this shows U (up) or D (down). A hyphen (-) means that VPN monitoring is not enabled for this SA. Note that vsys always shows 0.

Note that the ID number is 131073 in the output. This is the index value and is unique for each IPsec SA. You can view more details for a particular security association as shown here:

user@CORPORATE> show security ipsec security-associations index 131073 detail

In this output, local identity and remote identity elements are displayed. These elements comprise the proxy ID for this SA. Proxy ID mismatch is a very common reason for phase 2 failing to complete. If no IPsec SA is listed, then confirm the phase 2 proposals and check that the proxy ID settings are correct for both peers. Note that for route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, service=any. This can cause issues if you have multiple route-based VPNs from the same peer IP, in which case, you must specify unique proxy IDs for each IPsec SA. Also for some third-party vendors, you might need to manually enter the proxy ID to match. Another common reason for phase 2 failing to complete can be not specifying secure tunnel (ST) interface binding. If IPsec cannot complete, check the kmd log.

Verifying Statistics and Errors for an IPsec SA

Purpose

Verify ESP and authentication header counters, and check for any errors with a particular IPsec security association.

Action

user@CORPORATE> show security ipsec statistics index 131073

You normally do not want to see error values other than zero. However, if you are experiencing packet loss issues across a VPN, then one approach is to run the command multiple times and confirm that the encrypted and decrypted packet counters are incrementing. Also, determine whether any of the error counters increment while you are experiencing the issue. It might also be necessary to enable security flow traceoptions to determine and troubleshoot ESP packets that are experiencing errors.

Verifying Traffic Flow Across the VPN

Purpose

Test traffic flow across the VPN after phase 1 and phase 2 have completed successfully. You can test traffic flow by using the ping command. You can ping from the local host PC to the remote host PC. You can also initiate pings from the Junos OS-based device.

Action

Use the ping command to test connectivity from the Corporate site Junos OS-based device to the Remote site PC host.

user@CORPORATE> ping 10.0.20.10 interface ge-0/0/3.0 count 5

To reach the Remote site network, the destination address must be the remote peer static NAT address. Note that pings are initiated from the Junos OS-based device, that the source interface or source address must be specified to ensure that correct route lookup takes place, and that the appropriate zones are referenced in policy lookup.

In this example, ge-0/0/3.0 resides in the same security zone as the Corporate host PC. Therefore, interface ge-0/0/3.0 or the IP address of the interface must be specified in pings, so that the policy lookup can be from zone trust to zone vpn.

If pings fail, this could indicate an issue with routing, policy, end host, or perhaps with the encryption/decryption of the ESP packets. One way to check is to view IPsec statistics to see if any errors have been reported. Also, you can confirm end host connectivity by pinging from a host on the same subnet as the end host. If it is reachable by other hosts, the end host is probably not the reason for the issue. For routing and policy issues, enable security flow traceoptions.