@zegor_mjol,
Try the setup on your actual device (380) and see if it works. Making changes to SF tunnels and hitting apply will not affect any connections and will not affect any tunnels you haven’t actually changed.
I would try this setup 1 SF tunnel for each of the devices to the 380, but in the profiles, switch the “Data Port” to something higher than 4701, 4702 every time you add a new P2P profile to the 380. See if that might fix the problem. You can even go higher, just get it out of the range of a possible port that SF might be using already.
I appreciate the suggestion, but for a production router with a good bunch of connections this experiment is not viable.
As a variant, we have tried separating the particular connection as a P2P connection (using IC2), and with a different data port (picked 5500). No go.
Mixing IC2 definitions with local definitions is not allowed, so defining something local would require a dismantling of the whole hub infrastructure, and that we’re not ready to do.
As a PS: We have a similar PepVPN (no bonding) architecture for another connection to the same B380: B1<->BR1<->B380, and that works just fine.
Cheers,
Z
And of course he figured it out 
The issue was identified, and the resolution (as far as the Peplink devices are concerned) was elsewhere:
It was not a Peplink device issue.
The HD2 and the Transit communicated via a VLAN defined on the switch, and even when there were only those two devices on the VLAN they could not establish the SpeedFusion connection (though they connected perfectly in all other aspects, such as regular UDP and TCP access from the HD2 via the Transit to the internet).
Removing the switch and making a direct, wired connection solved the problem.
Now I have to figure out what’s wrong with the switch or its configuration…
[Update:]
The switch interpreted the SpeedFusion connection as a DOS attack and shut it down. It has now been (firmly) instructed not to do that.
As always, thanks @TK_Liew and kudos to @Paul_Mossip.
Cheers,
Z
4 Likes
That’s interesting , did not know/suspect that!
Thanks for sticking with everyone and glad you got a solution.
The issue was identified, and the resolution (as far as the Peplink devices are concerned) was elsewhere: