Hub receives IKE packet from new hub but does not reply

[slouw]

Dear FortiExperts
Why when my new VPN spoke sends IKE initiation packets to my existing Hub, does my hub not reply?
I have found this "IKEv2 exchange=SA_INIT id" of 4f0472f511bd4d4a in debugs on both spoke and hub.
So I can related the debugs to each other.
The spoke is repeatedly sending IKE packets as seen with this pattern:

2023-11-03 12:08:37.961125 ike 3:pri_bms: schedule auto-negotiate
2023-11-03 12:08:38.970872 ike 3:pri_bms: auto-negotiate connection
2023-11-03 12:08:38.970996 ike 3:pri_bms: created connection: 0x8806da0 5 192.168.1.23->203.57.169.172:500.
2023-11-03 12:08:38.971031 ike 3:pri_bms:pri_bms: chosen to populate IKE_SA traffic-selectors
2023-11-03 12:08:38.971095 ike 3:pri_bms: no suitable IKE_SA, queuing CHILD_SA request and initiating IKE_SA negotiation
2023-11-03 12:08:38.971166 ike 3:pri_bms:613: generate DH public value request queued
2023-11-03 12:08:38.971515 ike 3:pri_bms:613: out 4F0472F511BD4D4A00000.. <<<truncated>>>   00000804000005000000080400000E0200003402E000000080000F101
2023-11-03 12:08:38.971645 ike 3:pri_bms:613: sent IKE msg (SA_INIT): 192.168.1.23:500->203.57.169.172:500, len=640, vrf=0, id=4f0472f511bd4d4a/0000000000000000

The hub for its part seem to signal receipt of the same packet thus:

2023-11-03 12:08:54.426652 ike 1: comes 206.83.119.226:61618->203.57.169.172:500,ifindex=26,vrf=0....
2023-11-03 12:08:54.426670 ike 1: IKEv2 exchange=SA_INIT id=4f0472f511bd4d4a/0000000000000000 len=640
2023-11-03 12:08:54.426681 ike 1: in 4F0472F511BD4D4A00000..<<<truncated>>> CFC5094B066C0CD601F66EC188810C441FC5BFF290000080000402E000000080000F101

It then seems to check every IPSec tunnel it has before giving this depressing output:

2023-11-03 12:08:54.429066 ike 1:4f0472f511bd4d4a/0000000000000000:27452: no proposal chosen
2023-11-03 12:08:54.429081 ike Negotiate SA Error:
2023-11-03 12:08:54.429084 ike
2023-11-03 12:08:54.429087 ike [10807]

I can see no clue why no proposal is in fact chosen.

Googling IKE error 10807 give me nothing.

There is no nice and neat debug output telling me for instance that there is a pre-shared key mismatch (Though there in fact could be. I am not sure)

Any suggestions much appreciated.
From other posts I know to check there are matching proposals on both sides.
See below.

Does it look ok?

 

[pminarik · Accepted solution]

Network overlay IDs (set to 9 on the hub) need to match for a phase1 match.

[slouw]

Thanks!

Where might I find in the GUI where the network overlay ID is set on my hub?
I am looking for this in the GUI:

set network-id 9

I have looked  in these 2 places see below

Interfaces >> Port18 >> [[Tunnel]] >> Edit/View

VPN >> IPSec Tunnels >> [[Tunnel]] > Edit/View

[pminarik]

I'm only used to this in the CLI. :)
Anyway, I checked, and this is not exposed as an option in the GUI at all, even in 7.4.

[dowre70]

I've got similar success story with replacing my tp-link router+mesh+switches to linksys velop + linksys switches. Same story, not advising or recommending linksys velop, just saying that network/wi-fi was the actual issue.