• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Three location VPN setup

Grimmy311

Limp Gawd
Joined
Oct 11, 2011
Messages
148
I have a client with multiple locations and a primary hub we'll call that MAIN. They are a client that requires HA and they would like to implement a solution that if their primary location were to have some type of natural disaster they want to be able to reroute all traffic to their OFFSITE DR location which hosts copies of their VMs/Servers/Apps/Etc...
They want to have their own DR site that all sites will route traffic through to the OFFSITE DR. So, instead of creating a VPN connection from all separate sites to the OFFSITE DR they want to have all sites route traffic through their MAIN DR to the OFFSITE DR. We tried to test this last week but ran into a snag.

SECONDARY SITE (10.0.10.0) <===VPN IPSEC===> MAIN DR (10.0.11.0) <====VPN IPSEC===> OFFSITE DR (10.0.12.0)

The VPN from MAIN DR to OFFSITE DR worked flawlessly, we could get to the backup servers and all services/apps worked without issues. Where we ran into trouble was getting the secondary site up and running. We could communicate back and forth from SECONDARY SITE to MAIN DR but no further.

My question is does the OFFSITE DR need to have the SECONDARY SITE subnet listed in the presented VPN networks for traffic to flow properly? Or do I need to setup static routes from SECONDARY SITE to OFFSITE DR? I'm sure this is pretty basic but unfortunately it sort of got dropped in my lap last minute and I don't have much experience with this kind of setup.

Just to be clear IF the MAIN went down. They want to then be able to enable a VPN from the MAIN DR to OFFSITE DR and from the separate sites enable a VPN to the MAIN DR that will give them access to the resources at the OFFSITE DR.
 
What happens when the main site power goes out or burns down?Doesn't sound like a very good DR strategy...

regardless you need a static route in the secondary site routing table to tell it jump to main dr site to get to offsite DR location. You also need route in offsite DR pointing to VPN link to get back to the secondary site.
 
Sorry I may not have explained it well, that is the point of this setup.

Currently 13 locations connect into the MAIN for resources. Every night the servers get copied to the OFFSITE DR site (in another state). The idea is that IF the main site were to burn down, lose power, or any other natural disaster, the 13 locations could enable their VPN to the MAIN DR firewall which is connected to the OFFSITE DR site and continue to work normally. What we do to test is disconnect the VPN from one location to the MAIN and enable to VPN from that location to the MAIN DR. The VPNs come up fine, but from that location you cannot access any resources at the OFFSITE DR. So the path of data should be like this

SECONDARY SITE =====> MAIN DR =====> OFFSITE DR

and

OFFSITE DR =====> MAIN DR =====> SECONDARY SITE

Currently when testing I get this

SECONDARY SITE <====> MAIN DR <=====> OFFSITE DR

SECONDARY SITE <xxxx> OFFSITE DR

Sorry for the poor diagram, but basically I can't get to any of the resources at the OFFSITE DR from the SECONDARY SITE.

I also realize I could just create a tunnel from SECONDARY SITE directly to OFFSITE DR and have it work, but for auditing purposes all traffic needs to run through the MAIN DR to get to the OFFSITE DR.
 
You're right, it's hard to follow. You reference MAIN and MAIN DR, as well as Offsite DR. Are you saying the traffic has to go through 2 VPN tunnels to get to the backup site? The router hosting the VPN tunnel at the first site knows nothing about the second tunnel, so it doesn't know where to route traffic destined for that subnet. The first router needs to know to forward traffic destined for the offsite subnet over the first VPN tunnel, so the router at the main dr can route it across the second tunnel.

But the next question is why would they not connect directly to the secondary site, so only 1 tunnel is needed? It sounds like they would already have to do manual VPN changes in a DR scenario anyway.
 
You're right, it's hard to follow. You reference MAIN and MAIN DR, as well as Offsite DR. Are you saying the traffic has to go through 2 VPN tunnels to get to the backup site? The router hosting the VPN tunnel at the first site knows nothing about the second tunnel, so it doesn't know where to route traffic destined for that subnet. The first router needs to know to forward traffic destined for the offsite subnet over the first VPN tunnel, so the router at the main dr can route it across the second tunnel.

But the next question is why would they not connect directly to the secondary site, so only 1 tunnel is needed? It sounds like they would already have to do manual VPN changes in a DR scenario anyway.

You are exactly right. The traffic will need to go from site1(Main) to sitem(Main DR) to site2(Offsite DR).

I actually asked them the same question, in my mind you are then pushing all 13 locations they have through ONE site to access a offsite DR. Seems silly in my mind as if that site were to have issues or not have the ability to handle the traffic load then they are completely down again. I've spoken with them and we are now pursuing direct connections from each site to the OFFSITE DR and leaving out the middle man. Thank you very much for you help.
 
I've spoken with them and we are now pursuing direct connections from each site to the OFFSITE DR and leaving out the middle man. Thank you very much for you help.

Assuming they have static IP's, an IPSEC encrypted site-to-site tunnel with a VPN appliance/router + OSPF for routing should satisfy their security needs assuming they have appropriate physical security at the sites. Don't forget about proper firewall setup between sites as well.

I deal with several clients that deal with data that require encryption on disk, encrypted transmission over VPN as well as from client to server, two factor authentication and last but not least, two forms of physical security to the servers/routers.

Be sure to check with your client to see what level of physical security to the routers is defined by their security requirements. Typically it's defined as no windows, individual access to the room (with logging) and a key to gain access to the rack within that room. We also go one step further and have the key to the rack in a separate, access controlled room in an access controlled key-box. All with video surveillance of course too. With all that security you may also have to start dealing with fire control/suppression code based on the restricted access to the room. Check with your local fire-chief.
 
Last edited:
Back
Top