Dynamic tunnel interface creation

When configuring route-based IPsec dialup tunnels, the net-device setting controls how traffic is routed on the hub:

config vpn ipsec phase1-interface
    edit "Spoke"
        set type dynamic
        set net-device {disable | enable}
        set tunnel-search {selectors | nexthop}
    next
end

The key settings are net-device and tunnel-search. When net-device is disabled, all dialup tunnels share an interface on the hub. The tunnel selection process is based on the tunnel search method. Using a shared interface eliminates the time needed for dynamic interface creation and tear-down. When net-device is enabled, dynamic interfaces are created on the hub for each dialup tunnel. This means that potentially many dynamic interfaces could be created at start-up in a large scale deployment.

Behavior with net-device disabled

After a successful dial-in negotiation, the following occurs on the hub:

1. A dialup tunnel is created for each successful dial-in.
2. The tunnel name takes the form of <phase1Name_index>.
   1. For example, the first dialup tunnel to connect is Spoke_1, the second is Spoke_2, and so on.

      To view the tunnel name and the phase 1 parent:

      Hub # diagnose vpn tunnel list name Spoke_3
      list ipsec tunnel by names in vd 0
      ------------------------------------------------------
      name=Spoke_3 ver=1 serial=8 198.51.100.1:0->198.51.100.4:0
      bound_if=4 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/320 options[0140]=search-nexthop rgwy_chg parent=Spoke index=3

3. No dynamic interface is created.
4. The networks accessible over dialup tunnels are all bound to the same shared phase 1 interface.
   1. To view the routing table:

      Hub # get router info routing-table bgp
      Routing table for VRF=0
      B       192.168.2.0/24 [200/0] via 10.10.10.2, Spoke, 01:04:49
      B       192.168.3.0/24 [200/0] via 10.10.10.3, Spoke, 01:04:47
      B       192.168.4.0/24 [200/0] via 10.10.10.4, Spoke, 00:35:01
      B       192.168.5.0/24 [200/0] via 10.10.10.5, Spoke, 01:04:51

When forwarding a packet to the spoke shared interface:

1. The cleartext packet is first sent to the IPsec engine.
2. The IPsec engine finds which tunnel's IPsec security association (SA) is used for protecting this packet.
3. The search logic is based on set tunnel-search {selectors | nexthop}.

Tunnel search selectors

This is the default setting, which dictates that IPsec routes are learned from the traffic selectors of the IPsec SA negotiation. These routes are also called IKE routes, and can be displayed using diagnose vpn ike routes list.

Tunnel search next hop

This setting is used when you want IPsec routes to be learned from a dynamic routing protocol. The IPsec engine checks the search method associated with the shared interface spoke, and searches the tunnel index associated with the next hop. In this example, while searching for the index associated with next hop 10.10.10.4, index 3 is found corresponding to the Spoke_3 tunnel.

Hub # diagnose vpn tunnel list name Spoke
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=Spoke ver=1 serial=1 198.51.100.1:0->0.0.0.0:0
bound_if=4 lgwy=static/1 tun=intf/0 mode=dialup/2 encap=none/64 options[0040]=search-nexthop
proxyid_num=0 child_num=4 refcnt=26 ilast=4159 olast=4159 ad=/0 itn-status=7b
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
run_tally=4
ipv4 route tree:
10.10.10.2 2
10.10.10.3 0
10.10.10.4 3
10.10.10.5 1
198.51.100.2 2
198.51.100.3 0
198.51.100.4 3
198.51.100.5 1

Behavior with net-device enabled

After a successful dial-in negotiation, the following occurs on the hub:

1. A dialup tunnel is created for each successful dial-in.
2. The tunnel name takes the form of <phase1Name_index>.
   1. For example, the first dialup tunnel to connect is Spoke_1, the second is Spoke_2, and so on.

      To view the tunnel name and the phase 1 parent:

      Hub # diagnose vpn tunnel list name Spoke_3
      list ipsec tunnel by names in vd 0
      ------------------------------------------------------
      name=Spoke_3 ver=1 serial=6 198.51.100.1:0->198.51.100.4:0
      bound_if=4 lgwy=static/1 tun=intf/0 mode=dial_inst/3 encap=none/0 parent=Spoke index=3

3. A dynamic interface is created for each dialup tunnel.
   1. To view the interface list:

      Hub # diagnose netlink interface list | grep "Spoke_"
      if=Spoke_0 family=00 type=768 index=22 mtu=1438 link=16 master=0
      if=Spoke_1 family=00 type=768 index=23 mtu=1438 link=16 master=0
      if=Spoke_2 family=00 type=768 index=24 mtu=1438 link=16 master=0
      if=Spoke_3 family=00 type=768 index=26 mtu=1438 link=16 master=0

4. The networks accessible over dialup tunnels are bound to the corresponding tunnel interface.
   1. To view the routing table:

      Hub # get router info routing-table bgp
      Routing table for VRF=0
      B       192.168.2.0/24 [200/0] via 10.10.10.2, Spoke_0, 01:04:49
      B       192.168.3.0/24 [200/0] via 10.10.10.3, Spoke_1, 01:04:47
      B       192.168.4.0/24 [200/0] via 10.10.10.4, Spoke_3, 00:35:01
      B       192.168.5.0/24 [200/0] via 10.10.10.5, Spoke_2, 01:04:51

When forwarding a packet to the dialup IPsec interface:

1. The cleartext packet sent to the dynamic interface is sent to the IPsec engine.
2. The IPsec engine protects the cleartext packets with the IPsec security association (SA) of the corresponding tunnel.
3. The ESP packet is then sent on the wire.