You’re going to need either a tunnel between each location, or, one hub and multiple spokes, using SNAT rules to shepherd traffic between the spokes to each other.
It’s not simple, and if 2 needs to talk to 3, then the easiest way to make that happen is to create a tunnel from 2 to 3 and not route traffic from 2 through 1 to 3. This doesn’t scale well, but is easier.
Otherwise, you need SNAT rules for traffic from 2->3 such that it goes over the IPSec tunnels and uses 1 as the intermediary and also matches the traffic selectors.
I got it working - without knowing what happened before…
You can trust Me, I used all possible combinations before - but only NOW it is successfully interconnected… I will look further if it works and stays connected…
One fact - perhaps not so importatnt - latest updates today applied… for to be sure… But before there were also identical versions of IPFIRE running but without success…
Not like before - some connected, some connecting, some disconnected… Without reasonable arguments… Perhaps some small errors in build are corrected, perhaps the gods of internet have been malicious enough on Me
But important is - it works for now !
p.s. I can ping from - to:
TN -> TT
TT -> TN
TN -> ZA
ZA -> TN
TT -> ZA
ZA -> TT
p.s.2: Perhaps it can be due a fact, how I have started all the IPSECs on FWs. First - have all created - prepaired all IPSECs stopped, but with checkmark enabled as “enabled” - and then ran through all 3 tabs and quickly clicked “save” on every FW GUI frontend… So all IPSEC daemons started in very small fraction of time… No other idea (normal idea is that developers have corrected some interconnection bugs in case more ipsecs are interconnected…)
p.s.3: WITHOUT TWEAKING IPTABLES OR SOME RULES OR ANYTHING… Simple - used correct naming identification and one passphrase… Nothing more.