I can understand your frustration but the curt comments you have received are correct. Phase 2s don't work like that - IPSEC is not routing and it's certainly not a "cloud" that you simply bung packets into and hope that they know where to go. Also ANY packets that do not match both parts of the P2 will not go over the tunnel. This is especially important to remember if you try to daisy-chain sites together. eg, three sites:
A – B -- C
To fully connect these you could do this with this number of P2s and the parenthesized (bracketed) number of P1s:
A: AB, AB(C) (1 x P1)
B: BA, BC, B(C)A (3 x P1)
C: CB, CB(A) (1 x P1)
I think I got that right and that's a very simple star with 3 sites only. Add a site D, only connected to C and the permutations become horrendous. With a mesh instead, where each site is connected to all the others and adding D (each pair is 1 P1 and a P2):
A: AB, AC, AD
B: BA, BC, BD
C: CA, CB, CD
D: DA, DB, DC
ie (n-1)^2 Phase 1. With the daisy-chain there is a different relation which someone could perhaps chime in with and for the simple case we could work out the fewest number of P1s and 2s required. At the start of that discussion we'll be assuming a spherical tunnel 8)
.... or not. Daisy chaining beyond two hops is really silly and even two hops should only be used if needed to get around a proprietary (Safe@Office anyone?) or technical limitation to the number of P1s available on a device. It depends on more links working and is horrible to work out.
This far I have deliberately shown the worst case, although I haven't even started on multiple subnets at each site. Simply multiply the P2 numbers above by the number of subnets at both sites involved - yes that's effectively squaring them. eg 2 subnets at A and B = 4 x P2s and 2 P1s in total. Hmmm 8 sites and say 4 VLANs each is going to take some time unless there are some shortcuts. Nominally we have:
(8-1)^2 = 7 * 7 = 49 P1s
4^2 = 16 P2s per P1 => 49 * 16 = 748 P2s
Now we get to the reasons why you might want to think about your network design before you start cranking out IPSEC on such a setup.
There are at least two strategies that can help reduce the sheer number of P1s and P2s:
1. Do all sites need to reach all other sites?
If you have an HQ site + satellites where all the sat sites only need to get to HQ then probably no. This reduces the number of P1s to
2(n-1) = 2 * (8 - 1) = 14 (down from 49) in this example.
However, if you have an AD DC at each site, you must fixup AD S&S so that the DCs can all sync properly. The KCC is shit at working out things for itself. See MS's docs for site bridging and all that bollocks. If you are using eDir (unlikely, sadly) or OpenLDAP it's easier to deal with. Other systems may need to be dealt with in various ways.
2. Can we combine all the subnets at a site into one for the purposes of IPSEC?
Careful choice of subnets at each site can reduce the number of P2s from n*m (n is the number at one site and m is the number at another) to 2 P2s per P1 - this can really scale! For example:
Site A has 20 VLANs: 10.1.{1,2,3 ... 20}.0/24
Site B has 50 VLANs: 10.2.{1,2,3 ... 50}.0/24
With IPSEC we setup the P1 in the usual way to join site A and B but for P2 we can refer to Site A's subnets as 10.1.0.0/16 and Site B's as 10.2.0.0/16 for 1 P2 at each end, or 2 P2s in total. As an added bonus we can add another (253 minus the number of subnets in use) subnets at each site and it will still work.
Results for 8 sites, each with 4 subnets:
Random set up => (n-1)^2 P1 and (n-1)^2 * sum(n * m) P2
My notation for the P2s is not rigorous and is missing some subscripts and stuff.
49 P1s and and an eyewatering 748 P2s
Simplified networking and collapsable subnets => 2(n-1) P1 and 2(n-1) P2
14 P1s and 14 P2s - Lovely
OK, so we don't have your network layout so can't really design it for you. However if it was me, I'd probably start a process of network renumbering, given that you seem to be seeking a magic bullet of VPNs - this isn't one. It should not be a really big deal. You should be making good use of DHCP where applicable and DNS as well to remove many obstacles to doing this sort of thing. However I have had to fix far too many bloody networks that were .... *&^^%$£ ...... whatever.
You should now have more than enough information to decide what to do.
Cheers
Jon
