FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
GeorgeZhong
Staff
Staff
Article Id 293762
Description

This article describes the usage of the ‘auto-discovery-crossover’ option in ADVPN setup, which is a new feature introduced in FortiOS 7.2.5. From this version, the ‘auto-discovery-crossover’ option has been added under the ‘config vpn ipsec phase1-interface’ configuration to block or allow (default) the set-up of shortcut tunnels between different network IDs.

Scope FortiGate v7.2.5+, ADVPN.
Solution

This article uses below ADVPN hub-and-spoke topology as an example. Each spoke has 2 IPsec tunnels (‘MPLS’ & ‘INET’) with different ‘network-id’ to connect to the Hub:

 

GeorgeZhong_0-1705033877287.png

 

When the PC on spoke-1 sends the first packet to the PC on spoke-2 via the hub, the hub will forward the packet the spoke-2 and then send a shortcut offer to spoke-1. Then the shortcut tunnel will be established between these two spokes over two IPsec tunnels the first packet has passed through.

 

In the FortiOS version before 7.2.5, Policy Route was introduced to route the traffic to the same tunnel interface on the hub to make sure the shortcut will establish on the same overlay. See reference: 

Technical Tip: Usage of overlay stickiness in multiple overlay links in an ADVPN/SDWAN setup

 

However, if the ‘Spoke_2_ MPLS’ tunnel between the hub and spoke-2 is down for some reason, the next hop in the policy route on the hub will be no longer available. So, this policy route will be skipped:

 

GeorgeZhong_1-1705033877293.png

In this scenario, the first packet comes to the hub via the tunnel ‘MPLS’ from spoke-1 but will be forwarded to spoke-2 via ‘INET’.

The shortcut will be established by crossing these two tunnels again.

 

Spoke-1:

 

GeorgeZhong_2-1705033877296.jpeg

 

Spoke-2:

 

GeorgeZhong_3-1705033877299.jpeg

 

From 7.2.5 onward, the ‘auto-discovery-crossover’ option has been added under ‘config vpn ipsec phase1-interface’ configuration.

 

config vpn ipsec phase1-interface

    edit <name>

        set auto-discovery-crossover {allow (default) | block}    

    next

end

 

In this case, it is possible to choose to set the ‘auto-discovery-crossover’ to ‘block’ either on the hub (auto-discovery sender) or spoke (auto-discovery receiver). After that, the upcoming packet between these two spokes will keep going via hub until the MPLS link to spoke-2 has been restored.

 

Configuration and IKE debug detail.

When blocking it on the hub, the configuration is as follows:

 

config vpn ipsec phase1-interface

    edit "Hub_MPLS"

          set auto-discovery-crossover block

    next

    edit "Hub_INET"

          set auto-discovery-crossover block

    next

end

 

In the below IKE debug output on the hub, it is possible to see when spoke-1 sends the first packet to spoke-2 via a hub, the shortcut trigger is ignored since crossover is not allowed. Then no shortcut will be established between INET and MPLS.

 

2024-01-12 14:46:06.556162 ike 0: shortcut Hub_MPLS_0:10.56.245.12:0 to Hub_INET_1:10.56.242.10:0 for 10.30.1.2->10.2.0.197 0

2024-01-12 14:46:06.557141 ike 0:Hub_MPLS_0 crossover not allowed, shortcut trigger ignored

 

When blocking ‘crossover’ on the spoke-1, the configuration is as follows:

 

config vpn ipsec phase1-interface

    edit "Spoke_1_MPLS"

        set auto-discovery-crossover block

   next

    edit " Spoke_1_INET"

        set auto-discovery-crossover block

   next

end

 

In the below IKE debug output, it is possible to see that spoke-1 has received the shortcut offer and initiated the query, but the responder (spoke-2) rejected it and replied with ‘failure’ since the initiator (spoke-1) is having ‘crossover’ disabled.

 

Spoke-1:

 

2024-01-12 14:56:01.147040 ike 0:Spoke_1_MPLS:7423: processing notify type SHORTCUT_OFFER

2024-01-12 14:56:01.147828 ike 0:Spoke_1_MPLS: shortcut-offer 10.30.1.2->10.2.0.197 0 psk 64 ppk 0 ver 2 mode 0, peer-addr 10.56.242.10:0

2024-01-12 14:56:01.148878 ike 0 looking up shortcut by addr 10.2.0.197, name Spoke_1_MPLS, peer-addr 10.56.242.10:0

2024-01-12 14:56:01.149790 ike 0:Spoke_1_MPLS: send shortcut-query 3109485644012651307 0c71670b1be028e7/0000000000000000 10.56.245.12 10.30.1.2->10.2.0.197 0 psk 64 ttl 32 nat 0 ver 2 mode 0 network-id 11

2024-01-12 14:56:01.271020 ike 0:Spoke_1_MPLS:7423: processing notify type SHORTCUT_REPLY

2024-01-12 14:56:01.271931 ike 0:Spoke_1_MPLS: recv shortcut-reply 3109485644012651307 0c71670b1be028e7/0000000000000000 10.56.242.10 to 10.30.1.2 0 psk 64 ppk 0 ver 2 mode 0 ext-mapping 10.56.242.10:0, network-id 11/12

2024-01-12 14:56:01.275572 ike 0:Spoke_1_MPLS: shortcut responder rejected shortcut exchange

 

Spoke-2:

 

2024-01-12 14:56:01.223301 ike 0:Spoke_2_INET:35: processing notify type SHORTCUT_QUERY

2024-01-12 14:56:01.224390 ike 0:Spoke_2_INET: recv shortcut-query 3109485644012651307 0c71670b1be028e7/0000000000000000 10.56.245.12 10.30.1.2->10.2.0.197 0 psk 64 ppk 0 ttl 31 nat 0 ver 2 mode 0 network-id 11

2024-01-12 14:56:01.227814 ike 0:Spoke_2_INET: auto-discovery crossover detected but crossover is disabled on (initiator ), reply with failure

2024-01-12 14:56:01.229291 ike 0:Spoke_2_INET: send shortcut-reply 3109485644012651307 0c71670b1be028e7/0000000000000000 10.56.242.10 to 10.30.1.2 0 psk 64 ppk 0 ver 2 mode 0 network-id 11/12

 

When blocking ‘crossover’ on spoke-2, the configuration is as follows:

 

config vpn ipsec phase1-interface

    edit "Spoke_2_MPLS"

          set auto-discovery-crossover block

   next

   edit " Spoke_2_INET"

          set auto-discovery-crossover block

   next

end

 

In the below IKE debug output, it is possible to see the responder (spoke-2) rejected the shortcut request and replied with failure since the responder (spoke-2) has ‘crossover’ disabled.

 

Spoke-1:

 

2024-01-12 15:06:21.655841 ike 0:Spoke_1_MPLS:7485: processing notify type SHORTCUT_OFFER

2024-01-12 15:06:21.656623 ike 0:Spoke_1_MPLS: shortcut-offer 10.30.1.2->10.2.0.197 0 psk 64 ppk 0 ver 2 mode 0, peer-addr 10.56.242.10:0

2024-01-12 15:06:21.657723 ike 0 looking up shortcut by addr 10.2.0.197, name Spoke_1_MPLS, peer-addr 10.56.242.10:0

2024-01-12 15:06:21.658648 ike 0:Spoke_1_MPLS: send shortcut-query 5862598833297178811 2413775150bb7590/0000000000000000 10.56.245.12 10.30.1.2->10.2.0.197 0 psk 64 ttl 32 nat 0 ver 2 mode 0 network-id 11

2024-01-12 15:06:21.774634 ike 0:Spoke_1_MPLS:7485: processing notify type SHORTCUT_REPLY

2024-01-12 15:06:21.775446 ike 0:Spoke_1_MPLS: recv shortcut-reply 5862598833297178811 2413775150bb7590/0000000000000000 10.56.242.10 to 10.30.1.2 0 psk 64 ppk 0 ver 2 mode 0 ext-mapping 10.56.242.10:0, network-id 11/12

2024-01-12 15:06:21.778232 ike 0:Spoke_1_MPLS: shortcut responder rejected shortcut exchange

 

Spoke-2:

 

2024-01-12 15:06:21.731206 ike 0:Spoke_2_INET:36: processing notify type SHORTCUT_QUERY

2024-01-12 15:06:21.732197 ike 0:Spoke_2_INET: recv shortcut-query 5862598833297178811 2413775150bb7590/0000000000000000 10.56.245.12 10.30.1.2->10.2.0.197 0 psk 64 ppk 0 ttl 31 nat 0 ver 2 mode 0 network-id 11

2024-01-12 15:06:21.735566 ike 0:Spoke_2_INET: auto-discovery crossover detected but crossover is disabled on ( responder), reply with failure

2024-01-12 15:06:21.736988 ike 0:Spoke_2_INET: send shortcut-reply 5862598833297178811 2413775150bb7590/0000000000000000 10.56.242.10 to 10.30.1.2 0 psk 64 ppk 0 ver 2 mode 0 network-id 11/12

 

 

Related documents:

New features or enhancements

Phase 1 configuration

Technical Tip: Usage of overlay stickiness in multiple overlay links in an ADVPN/SDWAN setup