|
Consider the below scenario where network topology looks like:
Hub <--- VPN tunnel--->Spoke1
Hub <--- VPN tunnel ---> Spoke2
Spoke1<--- ADVPN shortcut ---> Spoke2 <----- This shortcut tunnel is not established.
The following IPs on each device are used:
Hub WAN IP (ISP1) - 200.52.10.1
Spoke1 WAN IP (ISP1) - 200.52.10.17
Spoke2 WAN IP (ISP1) - 200.52.10.33
Spoke1 Lan - 192.168.101.0/24
Spoke2 Lan - 192.168.102.0/24
The communication flow should be like below:
PC1(192.168.101.100) ---- SPOKE1 ----- ADVPN shortcut ---- SPOKE2 ---- PC2(192.168.102.100).
In the beginning, when traffic is passing through the HUB device, this unit will offer the shortcut negotiation to Spoke1 and the shortcut-query will be sent to the spoke2:
ike 0: comes 200.52.10.1:500->200.52.10.33:500,ifindex=3,vrf=0....
ike 0: IKEv1 exchange=Informational id=31132725521bd228/e929bb13aed42dd9:921f3dc0 len=236 vrf=0
ike 0: in 31132725521BD228E929BB13AED42DD908100501921F3DC0000000ECADE3C2DC9B1B22360CAC36BDDA773A7B0CBCFD6F8B02E11BD2BC09D30DE5B7FC0E601F72759CECAB49D4B89DB071DB529CB61
107BA95555EB5D54ED65A46D95995CE9CFEB625E4EFC717A10379F9CA78883A8BF28FD44B1C4E0F7FEC28D202538B59AB3F29948A76D9DC4C9238C4EE67E712191CB212FDED0BBB7EB4CBB3AD2D692139642340
F3869C293D27457ED08BA3FA9A6A1EFE3DB4173FC3E9A1EB9D4B359A88C75EB21F291395C8D7A47AF10238E3571EED18BBA031164F40CE0E2A6CBD9026DD2093CB30DB330891EBD4F62F
ike 0:HUB_ISP1:177: dec 31132725521BD228E929BB13AED42DD908100501921F3DC0000000EC0B0000183CAC64E1095A1465F523DFF52FEE34C1FC565778000000B0E415F10201007DFC7D1E6ACC021A498
61F0000000008001065E5DD3B18D541E8000000000000000000010004C0A8656400030004C0A8666400050004C8340A11000D0004C8340A11000F000201F4001000070040E0FFB6874A1625F01735B816DCD0A4
3937006F10B40DC789363F01A44220634130B067C6950D6923D1B877DFF963EA3D0D2A5926CF4504996278FF18D58CD8CD000B000101CC64B7000C0001012702100010000100000000F4F26F4B07F8FA07
ike 0:HUB_ISP1:177: notify msg received: SHORTCUT-QUERY
ike 0:HUB_ISP1: recv shortcut-query 9676293873703984765 65e5dd3b18d541e8/0000000000000000 200.52.10.17 192.168.101.100->192.168.102.100 0 psk 64 ppk 0 ttl 31 nat 0 ver
1 mode 1
ike 0:HUB_ISP1: iif 18 192.168.101.100->192.168.102.100 0 route lookup oif 6 port4 gwy 0.0.0.0
ike 0:HUB_ISP1:316 shortcut-query matches existing auto-discovery SA 65e5dd3b18d541e8/82d4b57669f75a49
The above message means that FortiGate is trying to establish a second VPN IPsec tunnel using the same interface, local-gw and remote-gw.
It is possible to review the ike gateway list to try to identify the first established tunnel:
B03_FG-SPOKE2 # diagnose vpn ike gateway list
vd: root/0
name: VPN_ToSPOKE1 <----- Site to Site tunnel between spokes.
version: 1
interface: port1 3
addr: 200.52.10.33:500 -> 200.52.10.17:500
tun_id: 200.52.10.17/::200.52.10.17
remote_location: 0.0.0.0
virtual-interface-addr: 2.2.2.2 -> 0.0.0.0
created: 4022s ago
IKE SA: created 1/2 established 1/1 time 10/10/10 ms
IPsec SA: created 2/2 established 1/1 time 10/10/10 ms
id/spi: 130 1ca16435550eeed0/76114b26a7579b24
direction: responder
status: established 3992-3992s ago = 10ms
proposal: 3des-sha1
key: b89c915032488e95-dca7245769429c14-b2dd48eebb2496a8
lifetime/rekey: 86400/82137
DPD sent/recv: 00000000/00000000
vd: root/0
name: HUB_ISP1
version: 1
interface: port1 3
addr: 200.52.10.33:500 -> 200.52.10.1:500
tun_id: 200.52.10.1/::200.52.10.1
remote_location: 0.0.0.0
virtual-interface-addr: 172.16.30.3 -> 172.16.30.1
created: 2410s ago
auto-discovery: 2 receiver
IKE SA: created 1/1 established 1/1 time 110/110/110 ms
IPsec SA: created 1/1 established 1/1 time 160/160/160 ms
id/spi: 177 31132725521bd228/e929bb13aed42dd9
direction: initiator
status: established 2410-2409s ago = 110ms
proposal: 3des-sha1
key: 2d94434b577827dd-d0bc3eae2f8ce4cf-a1bc827b92c5a2ca
lifetime/rekey: 86400/83690
DPD sent/recv: 00000000/00000000
This is why when a second tunnel (ADVPN shortcut) for the same local and remote IPs is tried to be established, the negotiation fails.
In this case, the first tunnel was configured before the ADVPN feature was enabled so as soon as this first tunnel is disabled, the new shortcut can be negotiated:
B03_FG-SPOKE2 # diagnose vpn ike gateway list
vd: root/0
name: HUB_ISP1
version: 1
interface: port1 3
addr: 200.52.10.33:500 -> 200.52.10.1:500
tun_id: 200.52.10.1/::200.52.10.1
remote_location: 0.0.0.0
virtual-interface-addr: 172.16.30.3 -> 172.16.30.1
created: 10417s ago
auto-discovery: 2 receiver
IKE SA: created 1/1 established 1/1 time 110/110/110 ms
IPsec SA: created 1/1 established 1/1 time 160/160/160 ms
id/spi: 177 31132725521bd228/e929bb13aed42dd9
direction: initiator
status: established 10417-10417s ago = 110ms
proposal: 3des-sha1
key: 2d94434b577827dd-d0bc3eae2f8ce4cf-a1bc827b92c5a2ca
lifetime/rekey: 86400/75682
DPD sent/recv: 00000002/00000000
vd: root/0
name: HUB_ISP1_0 <----- ADVPN shortcut.
version: 1
interface: port1 3
addr: 200.52.10.33:500 -> 200.52.10.17:500
tun_id: 172.16.30.2/::10.0.0.4
remote_location: 0.0.0.0
virtual-interface-addr: 172.16.30.3 -> 172.16.30.2
created: 7878s ago
peer-id: ISP1
peer-id-auth: no
auto-discovery: 2 receiver
IKE SA: created 1/1 established 1/1 time 220/220/220 ms
IPsec SA: created 1/1 established 1/1 time 70/70/70 ms
id/spi: 320 65e5dd3b18d541e8/9ae9c016b58d4ed2
direction: responder
status: established 7878-7878s ago = 220ms
proposal: 3des-sha1
key: 2a12d33471b87305-04348353bb1428f6-f053b53006b01bbd
lifetime/rekey: 86400/78251
DPD sent/recv: 00000002/00000000
peer-id: ISP1
vd: root/0
name: VPN_ToSPOKE1
version: 1
interface: port1 3
addr: 200.52.10.33:500 -> 200.52.10.17:500
tun_id: 200.52.10.17/::200.52.10.17
remote_location: 0.0.0.0
virtual-interface-addr: 2.2.2.2 -> 0.0.0.0
created: 0s ago
IKE SA: created 1/1
IPsec SA: created 1/1
id/spi: 582 650ee09bfc64252b/0000000000000000
direction: responder
status: connecting, state 3, started 0s ago <----- The first Site to Site tunnel was disabled to allow the shortcut.
|
