Hub-and-Spoke VPNs Using Next-Hop Tunnel Binding Overview

This topic includes the following sections:

• Fundamentals of Hub-and-Spoke VPNs in Junos OS
• Next-Hop Tunnel Binding Overview
• Understanding Route-to-Tunnel Mapping

Fundamentals of Hub-and-Spoke VPNs in Junos OS

Junos operating system (Junos OS) is Juniper Networks’ single operating system and provides the following features:

• Powerful operating system with rich IP services tool kit
• Unmatched IP dependability and security to ensure an efficient and predictable IP infrastructure
• Enhanced security and virtual private network (VPN) capabilities from Juniper Networks Firewall/IP Security (IPsec) VPN platforms, including the Secure Services Gateway (SSG) product family

This document provides an example for configuration of a multipoint interface, which is commonly used for hub-and-spoke environments. This example uses route-based VPNs from a central hub device to multiple spoke devices. Junos OS does not support a multipoint topology with policy-based VPNs.

This document is intended for network design and security engineers, as well as anyone who requires secure connectivity over public networks.

Next-Hop Tunnel Binding Overview

You can implement a hub-and-spoke VPN topology by using the route-based VPN concept in many ways. One way of implementing a hub-and-spoke VPN topology is to configure a separate secure tunnel (st0) logical unit for every spoke site. However, if a device has many associated peer devices, then the increased number of required interfaces can be a concern from the standpoint of scaling and management.

For example, the following limitation applies to:

• SSG platform – A maximum number of tunnel interfaces can be configured for the platform.
• Junos device – A maximum number of logical interface units that can be configured for the platform.

Junos OS supports the multipoint secure tunnel interfaces with the next-hop tunnel binding (NHTB) feature for easier management and scalability. NHTB enables a device to bind multiple IPsec security associations (SAs) to a single secure tunnel interface.

In this example:

• The secure tunnel interface operates as a point-to-point-type link by default.
• The Junos hub device is configured with st0 interface as a multipoint interface type in the st0 unit hierarchy. You need to configure multipoint interface only on the hub site; the spokes continue to use the default point-to-point mode.
• The Junos device binds multiple IPsec VPN tunnels to a single st0 interface unit.
• The Junos device links a specific destination to a specific IPsec tunnel bound to the same st0 interface, by using the following two tables:
  • Inet.0 route table
  • NHTB table
• The Junos device maps the next-hop IP address specified in the route table entry to a particular VPN tunnel specified in the NHTB table. With this feature, a single st0 interface can support many VPN tunnels.

The maximum number of IPsec tunnels is not limited by the number of st0 interfaces that you can create, but is limited by either of the following factor (whichever is lower) :

• Route table capacity
• Maximum number of dedicated IPsec tunnels allowed

To see the maximum route and tunnel capacities for your platform, refer to the relevant product data sheet.

Understanding Route-to-Tunnel Mapping

To manage the traffic among multiple IPsec VPN tunnels bound to the same st0 interface, the security device maps the next-hop gateway IP address specified in the route table to a particular IPsec tunnel name. This scenario is explained in this section with reference to Figure 1.

The following settings are assumed for the local security device and remote VPN peer devices:

• Local security device
  • A local security device with multiple IPsec VPNs bound to a single secure tunnel (st0) interface is in subnet 10.1.1.0/24.
  • A trusted LAN interface is in subnet 10.10.10.0/24.
  • The st0.0 interface is configured in multipoint mode.
• Remote VPN peers settings
  • The remote VPN peers with fixed st0.0 interface IP addresses are all within the same 10.1.1.0/24 subnet as the local device st0 interface.
  • The remote trusted subnets are 10.20.10.0/24, 10.30.10.0/24, and 10.40.10.0/24.
  • The st0.0 interface is configured in point-to-point mode.

Figure 1 shows the local device routing traffic sent from 10.10.10.10 to 10.30.10.10 through the st0.0 interface and then routed the traffic through VPN2.

Table 1 shows the mapping of entries in the route table to the entries in the NHTB table.

The following is an explanation of the scenario in Figure 1 and in Table 1:

1. You can use a dynamic routing protocol (for example, OSPF) to automatically populate the route table or you can add static routes manually. The next-hop IP address is the IP address of the remote peer’s st0 interface.
2. You can use one of the following options for an NHTB table:
   • Enter the next-hop addresses manually and bind them to the appropriate IPsec VPN tunnel.

     To link the route table and NHTB table, you must enter the same IP address as the next hop, along with the appropriate IPsec VPN name in the NHTB table.

   • Allow the Junos device to acquire the next-hop address automatically from the remote peer during Phase 2 negotiations using the NOTIFY_NS_NHTB_INFORM message. Note that this functionality is applicable only if both peers are Junos devices.

     During Phase 2 negotiations, the two Internet Key Exchange (IKE) peers can exchange st0 interface addresses automatically through the Notify message NOTIFY_NS_NHTB_INFORM (value 40001).

3. As listed in Table 1, the IP addresses for the next hop in the route table (which is also the same next-hop IP in the NHTB table) is the st0 interface IP address of the remote peer site. This next hop links the route –and consequently the st0 interface specified in the route -to a particular IPsec VPN tunnel.

Related Topics

• Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding
• Verifying Hub-and-Spoke VPN Configuration