Policy Based Hub and Spoke Configuration
scaudit last edited by
We currently have 10 offices linked together via policy based vpn’s. Each member of staff has a NSR dialup tunnel to the office they work at and all have a dialup tunnel to our NS50 at HQ. The rest of the offices have either a NS5XT or NS5GT in place. All site to site VPN’s terminate at the NS50 at HQ, as I have already said these are policy based VPNs. For this explanation the HQ site is site A and brach office(spoke) sites B-J. Currently sites B-J can all access resources at site A(HQ) but not from each other, which we need to rectify as each site has different data sets which staff now need access to from multiple locations. A hub and spoke topology seems to be the correct solution but we are using policy based vpn’s so I am not sure if this is possible and how we would configure the devices to allow this. We also want the staff to be able to dial in to site A(HQ) only and be able to access resources from any of the spoke sites. Again I am not sure if this is possible or what we need to configure to do this. We use IPSEC for dial-up VPN’s. I need to try to do this with as little disruption to the network as possible. I have seen a route based hub and spoke configuration guide on the juniper site but as we have a policy based set up i am not sure it would work in the same way.
MaxPipeline last edited by
I think a route-based would be the way to go. The problem with a policy-based approach is that the tunnel policy would typically only encompass a single network. This is especially true for the dialup client. So unless your policy on say site B encompasses all the networks for sites C-J, then the traffic for the other spokes would never traverse VPN to the hub site A.
So let’s say you add the sites C-J subnets on site B tunnel policy. Then the traffic for C-J would be able to traverse the VPN to site A. But then the next problem would be the routing once the packet is decrypted. Traffic would ingress on untrust zone, but the route lookup would be back out the untrust interface. So the policy would now be intrazone, that is from untrust to untrust. This would not be able to traverse your existing policy-based VPN from A to C-J.
By now, you should be able to see the many hurdles that you would need to overcome to get hub & spoke to work with policy-based. Why not go with a route-based? From a hub & spoke VPN point of view, this is much simpler to do since the traffic for the VPN is determined by whatever route you want to configure on each spoke. Plus even if you configure a separate tunnel interface for each site and place them in the same zone, then all you would have to do to allow all traffic between spokes is to disable the zone block.