Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

The Juniper Networks Junos operating system (Junos OS) provides the following features:

  • Powerful operating system with rich IP services tool kit

  • 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

A multipoint interface is commonly used for hub-and-spoke environments. The Example: Configuring Hub-and-Spoke VPNs using Next-Hop Tunnel Binding 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.

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 logical interface (st0) 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 OS device – A maximum number of logical interface units 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 the example:

  • The secure tunnel interface operates as a point-to-point link by default.

  • The Junos OS hub device is configured with the st0 interface as a multipoint interface type in the st0 unit hierarchy. You need to configure the multipoint interface only on the hub site; the spokes might continue to use the default point-to-point mode.

  • The Junos OS device binds multiple IPsec VPN tunnels to a single st0 interface unit.

  • The Junos OS 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 OS 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 factors (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 interface (st0) is in subnet

    • A trusted LAN interface is in subnet

    • The st0.0 logical interface is configured in multipoint mode.

  • Remote VPN peer settings

    • The remote VPN peers with fixed st0.0 logical interface IP addresses are all within the same subnet as the local device st0 interface.

    • The remote trusted subnets are,, and

    • The st0.0 logical interface is configured in point-to-point mode.

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

Figure 1: NHTB Routes and Table Entries
NHTB Routes and Table

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

Table 1: Mapping of Route Table Entries and NHTB Table Entries

Route Table


Next-Hop Tunnel Binding Table

IP Prefix

Next Hop


Next Hop



















The following is an explanation of the scenario in Figure 1 and in Table 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.

  • 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 OS device to automatically acquire the next-hop address from the remote peer and exchange st0 interface addresses during Phase 2 negotiations using the NOTIFY_NS_NHTB_INFORM message (value 40001). Note that this functionality is applicable only if both peers are Juniper Networks devices.

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


The multipoint st0 interface goes down when all interface virtual circuits are down and comes up when at least one interface virtual circuits is up.