1 of 1 people found this helpful
Yes, it is possible to configure a hub-and-spoke VPN environment on the Firewall. The Sidewinder, acting as a the hub, will have all the the 'spoke' remote networks defined in it's SA for the remote networks. Each 'spoke' will have the firewall's network and each 'hub' network defined as the remote network as well. We have set this up in the past in support and have found it works pretty well.
Additionally, you can add a rules to allow certain types of traffic between each of the hubs if you so desire. If you would like a more detailed description, please let me know and I will be happy to type something up for you.
1 of 1 people found this helpful
What you are describing is definitely possible. It does take some extra work visualizing how the VPN definitions are going to be setup (local and remote networks have to be manipulated so that each "spoke" thinks that the HQ Sidewinder has each subnet "behind" it). If you are having trouble with this, support can definitely help.
I do have to say that this particular setup does have it's problems. If the HQ Sidewinder goes down, or it's internet connection has issues, etc, then all of the VPNs will fail. A "mesh" setup will provide redundancy. Another negative is that all traffic needs to traverse two VPN tunnels. If each device were able to communicate directly with each other device, it would eliminate some of the problems.
Another thing I wanted to mention is Control Center. If all of your devices happen to be Firewall Enterprise's managed by Control Center, there is a wizard which will create all the necessary VPN definitions for you.
Thanks guys. You have kind of confirmed what I was suspecting - and, yes Matt, I get what you are saying about the potential fragilities with hub-and-spoke against mesh. If we were dealing with only a handful of spokes, then a mesh config is neither too complex or too arduous.
The issues my customer has are two fold:-
- Having to deal with 30+ remote office configurations (and counting)
- The fact that the remote offices are not running Sidewinder's also (with one or two exceptions, the remote sites are all running SnapGear Firewalls).
In addition to this, many of the remote sites have two internal subnets (a LAN subnet and a separate VoIP subnet), which I guess means that the network values in the VPN definition will need to be duplicated.
What the customer would like to do in an ideal world is be able to define a single VPN at the remote office to force *all* traffic from the remote over the VPN back to HQ. He tried to do this by specifying a remote network entry of 0.0.0.0/8, but this seemed to clash with the corresponding security association entry at the Sidewinder end because the correspoding "local" network definition at the Sidewinder-end would contain the specific local subnet definitions.
I know that as a Sidewinder forum, the SnapGear is somewhat out of bounds from a discussion point of view. Given that the SnapGear does allow for multiple remote subnet declarations, it should be possible to configure it's SA to contain the subnet definitions for both the HQ network and any of the other hubs it needs to communicate with.
I've used '0.0.0.0/0' successfully as the 'Local Network' in client-to-gateway VPNs. I have not tried it with gateway-to-gateway VPNs though. Either way, both ends need 0.0.0.0/0 configured, in the 'Remote network' on the Snapgear side and the 'Local Network' on the Sidewinder side.
I think that using 0.0.0.0 may work, but in my opinion, it may not be the best option. I think that what will happen is that the remote device (Snapgear) may try to tunnel everything through, instead of simply the traffic that goes to the other sites. That means all web traffic, mail, etc would go through the tunnel, even if it is destined for the internet(unless this is something you are looking for).
This is where the tricky part comes in. Pretending you have a tunnel to two Snapgears (from a Sidewinder) and each Snapgear has one network behind it:
subnet_a is behind Snapgear_a
subnet_b is behind Snapgear_b
subnet_c is behind the Sidewinder
The VPN definition on the Sidewinder for the tunnel to Snapgear_a needs to have a local network of subnet_c, as well as subnet_b.
The VPN definition on the Sidewinder for the tunnel to Snapgear_b needs to have a local network of subnet_c, as well as subnet_a.
The VPN configuration on Snapgear_a needs to have a remote network of subnet_c and subnet_b.
The VPN configuration on Snapgear_b needs to have a remote network of subnet_c and subnet_a.
This is difficult to describe, so I hope that you understand this.
Matt - you're right, it is difficult to describe!
However, I do understand what you are getting at and I have (with the help of one of my customers, who made their Sidewinder available to me) actually proved the hub and spoke scenario to work.
The hub was our Sidewinder here. The spokes were my customer's Sidewinder and a SnapGear sitting at my house. With no direct VPN between my home subnet and the customer's subnet, I created the VPNs (as described between home & office and office & customer) and was able to SSH from home to the internal IP address of my customer's Sidewinder.
As you've indicated, the trick is in being able to know which local & remote subnets to enter at each gateway. With a hub and two spokes it's not too bad. The customer has some 25-30 spokes (and many of the spokes have two subnets - voice and data), so depending on how many of the spoke sites need to see each other, I can envisage his list of local and remote network entries in each VPN definition being quite lengthy!
Thanks for your help.