hub and spoke route based vpn with multiple subnets

[Kevin]

Site A is the hub, and contains 5 subnets.

192.168.0.0/24

192.168.1.0/24

192.168.2.0/24

100.0.0.0/24

172.16.120.0/24

Site A has destination routes that contain the individual phase 1 for the spokes.

Site A has a zone interface created that contains all phase 1s.

Site A has policies created that allow all local subnets to the zone, and from the zone to the local subnets.

Site B/C are spokes.

B 10.97.1.0/24

C 10.1.0.0/16

Site B/C has routes that contain the hub A site, and a phase 1.

Site B/C has policies that contain the local subnet of the site, the hub site, and the remote spoke.

Site B/C has multiple phase 2s for each subnet at the hub site, and the alternate spoke.

However, I am unable to have Site B communicate with Site C.

Any ideas on what I am missing?

K

[rwpatterson]

You also need policies from the zone to the zone allowing "B" to "C" as well as "C" to "B".

[ede_pfau]

Now you need:

- on site B a route to site C subnet, pointing to the tunnel to the hub

- on site C a route to site B subnet, pointing to the tunnel to the hub

- to allow traffic between spokes, allow "intra-zone traffic" in the zone setup

If traffic from B to C is reaching the hub but isn't allowed through, you could create a new policy 'zone' to 'zone' and allow the type of traffic you are intending to allow.

[emnoc]

Site B/C has routes that contain the hub A site, and a phase 1.

Does B/C have routes to each other and the policies to allow for these traffic?

If your doing this a route-based vpn ( please say yes ) than you can easily enabled  OSPF over the vpn tunnels and have L3 reach spoke-2-hub or spoke-2-spoke.

If you have no  mandatory need to centralize all traffic to the 1-hub, you could also build a 3 spoke-spoke directly between B<>C. That's what I would do.

So traffic destinated to that spoke goes directly to that spoke. If that path is not available than it goes to the HUB and hopefully the hub vpn is up to that spoke. Now this model ( full-mesh ) doesn't scale worth a damm if you have like 7+ spokes but for a 3 spoke model it's great.

If you network/business grows and you need more  spokes,  than you decentralize some and place then in a new hub and then you route traffic between hub for the distant spoke. See my quick impromptu dwg. I just did something like but with juniper SRX branch core firewalls.

[Kevin]

Got it!

Policies were right, but my phase 2 proxy ids were reversed on the hub.

K