|
In a hub and spoke IPSec deployment, ADVPN is highly desired as it facilitates or orchestrates the establishment of an IPSec VPN tunnel between two spokes whenever needed (on-demand), automatically. However, this process or feature goes through some steps or stages before achieving this feat.
If any of the steps got hindered or impaired, it failed to establish the on-demand tunnel.
Here is a brief summary of what takes place for the ADVPN shortcut tunnel to form.
Topology:
LANs1---spoke1------hub------spoke2---LANs2
For traffic from LANs1 behind spoke1 to reach LANs2 behind spoke2 without going through the 'hub', which will introduce additional latency, and also spent hardware resources on the 'hub', a shortcut (direct IPSec VPN tunnel from spoke1 to spoke2) is needed.
- The shortcut formation process is triggered by data flow from spoke1 (or spoke2; it can be anyone that initiated the communication) through the hub with intended destination being spoke2's LANs2 (in this example).
- Shortcut negotiation is orchestrated by the HUB.
Note:
All shortcut communication is done via the 'hub' until a direct tunnel is negotiated between the two spokes.
- The shortcut is established.
Breakdown:
- spoke1 communicates with spoke2 via the hub.
- The hub sent a 'shortcut offer' to spoke1 (this 'shortcut offer' message contains information saying spoke2 can be reached directly on IP address x.x.x.x).
- spoke1 received the hub’s message and replied to the hub with a 'shortcut query'.
- hub receives the 'shortcut query' from spoke1 and FORWARD it to spoke2.
- spoke2 receives the 'shortcut query' from the hub and sends a 'shortcut reply' to the hub.
- The hub receives a 'shortcut reply' from spoke2 and FORWARD it to spoke1.
- spoke1 receives a 'shortcut reply' from the hub and initiates a DIRECT IPSec tunnel negotiation with spoke2.
- The shortcut (on-demand IPSec VPN tunnel) is formed if or once the negotiation is completed.
As it is glaring here, all these back-and-forths 'send and receive' require layer3 reachability.
If one or more of the IP subnets on LANs1 or LANs2 are used in VIP objects or IP Pool configuration, these can restrict the ADVPN shortcuts from forming, cause these objects sometimes dictate how routing is done.
It is most like facing this kind of issue if there are 10 locations and only one or two of them are unable to establish ADVPN shortcuts (the configuration is correct).
Another way to quickly figure this type of issue out is by collecting filtered IKE logs (the chronological steps or process described above will break somewhere in the middle):
diagnose debug reset
diagnose vpn ike log filter clear
diagnose vpn ike log-filter dst-addr4 x.x.x.x
diagnose debug app ike -1
diagnose debug enable
Delete the VIP object/s that pointed to LANs1 or LANs2 IP addresses, or change it to something else to fix the issue.
|
