Technical Tip: Transport Configuration Options in IKE - ADVPN SD-WAN v2.0

[isaac_ra]

Description	This article describes the transport options available in ADVPN SDWAN v2.0 and whether shortcut tunnels are established when auto, TCP, or UDP is used.
Scope	FortiGate v7.6.3.
Solution	When configuring IPSEC IKE Phase I, the following options are available as transport: CLI: config vpn ipsec phase1-interface     "edit TUNNEL1"         set transport auto|udp|tcp The topology below is being used: HUB IP: 1.1.1.1 (Loopback 98.27.93.1). Spoke1 IP: 2.2.2.2(Loopback 98.27.93.136). Spoke2 IP: 3.3.3.3 (Loopback 98.27.93.134). Scenario 1. Shortcuts are not established between spokes as the transport used is different: HUB is set to auto. Spoke1 is set to TCP. Spoke2 is set to UDP. The only IPsec tunnel established is via the HUB: Spoke1 # get vpn ipsec tunnel summary 'H1_INET' 1.1.1.1:11111 selectors(total,up): 2/2 rx(pkt,err): 256/0 tx(pkt,err): 268/22 Spoke1 # get router info routing-table details 98.27.93.134 Routing table for VRF=0 Routing entry for 98.27.93.0/22 Known via "bgp", distance 200, metric 0, best Last update 00:11:24 ago * vrf 0 98.27.93.1, tag 10 priority 1 (recursive via H1_INET tunnel 1.1.1.1) Scenario 2. All transports are set to AUTO, and UDP 500 is blocked on Spoke1. Spoke1 forms a tunnel towards the HUB, but no shortcut can be established with Spoke2, as the available transport does not match. Once communication over UDP 500 is allowed, the original TCP IPSEC tunnel to HUB remains up, but a shortcut is established over UDP: Spoke1 # diagnose vpn ike gateway list vd: root/0 name: H1_INET version: 2 interface: port2 4 addr: 2.2.2.2:3245 -> 1.1.1.1:11111 -> HUB over TCP 11111. ext addr: 2.2.2.2 tun_id: 1.1.1.1. remote_location: 98.27.93.1 vd: root/0 name: H1_INET_0 version: 2 interface: port2 4 addr: 2.2.2.2:500 -> 3.3.3.3:500 -> SPOKE over UDP 500. ext addr: 2.2.2.2 Spoke1 # get vpn ipsec tunnel summary 'H1_INET_0' 3.3.3.3:0 selectors(total,up): 3/3     -> Shortcut to Spoke. 'H1_INET' 1.1.1.1:11111 selectors(total,up): 2/2  -> Tunnel to HUB. Scenario 3. All transports are set to AUTO, and UDP is blocked on all sites. Tunnels between HUBs and Spokes are established via TCP: HUB # get vpn ipsec tunnel summary 'EDGE_INET_0' 2.2.2.2:2335  selectors(total,up): 2/2  rx(pkt,err): 862/0  tx(pkt,err): 465/0 'EDGE_INET_1' 3.3.3.3:1937  selectors(total,up): 2/2  rx(pkt,err): 1159/0  tx(pkt,err): 1114/0 No shortcuts between spokes can be established, and this can be verified by checking the IPsec tunnel list on Spoke3 after sending ICMP traffic between spokes: Spoke3 # get vpn ipsec tunnel summary 'H1_INET' 1.1.1.1:11111  selectors(total,up): 2/2  rx(pkt,err): 1158/0  tx(pkt,err): 1204/0 The traffic between spokes is always flowing via the HUB: Hub1# diagnose debug sniffer packet any "host 98.27.93.134 and 98.27.93.136" 4 Using Original Sniffing Mode interfaces=[any] filters=[host 98.27.93.134 and 98.27.93.136] 8.060740 EDGE_INET in 98.27.93.134 -> 98.27.93.136: icmp: echo request 8.061339 EDGE_INET out 98.27.93.134 -> 98.27.93.136: icmp: echo request 8.062525 EDGE_INET in 98.27.93.136 -> 98.27.93.134: icmp: echo reply 8.062536 EDGE_INET out 98.27.93.136 -> 98.27.93.134: icmp: echo reply 9.060972 EDGE_INET in 98.27.93.134 -> 98.27.93.136: icmp: echo request 9.061008 EDGE_INET out 98.27.93.134 -> 98.27.93.136: icmp: echo request