Bridging Datacenters for Disaster Recovery – Virtually, (Fri, Dec 19th)

Its been a while since we talked about Disaster Recovery issues – the last diary I posted on this was on using L2TPv3 to bridge your Datacenter / Server VLAN to the same VLAN at a DR site, over an arbitrary Layer 3 network (https://isc.sans.edu/diary/8704)

Since then, things have changed. Theres a real push to move DR sites from a rack in a remote office location to recognized IaaS cloud locations. With that change comes new issues. If you are using your own servers in a colocation facility, or using IaaS VM instances, rack space for a physical router may either come with a price tag, or if its all virtual, there might be no rack space at all.

In my situation, I had two clients in this position. The first customer simply wanted to move their DR site from a branch office to a colocation facility. The second customer is a Backup-as-a-Service Cloud Service Provider, who is creating a DR as a service product. In the first situation, there was no rack space to be had. In the second situation, the last thing a CSP wants is to have to give up physical rack space for every customer, and then deploy CSP owned hardware to the client site – that simply does not scale. In both cases, a VM running a router instance was clearly the preferred (or only) choice.

Virtual routers with enterprise features have been around for a while – back in the day we might have looked at quagga or zebra, but those have been folded into more mature products these days. In our case, we were looking at Vyatta (now owned by Brocade), or the open-source (free as in beer) fork of Vyatta – Vyos (vyos.net). Cisco is also in the game, their 1000V product supports IOS XE – their bridge L2 over L3 approach uses OTV rather than L2TPv3 or GRE. Youll find that most router vendors now have a virtual product.

Anyway, Working with Vyatta/Vyos configs isnt like Cisco at all – their configs look a whole lot more like you might see in JunOS. While Vyos supports the L2TPv3 protocol we know and love, its a brand new feature, and it comes with a note from the developer if you find any bugs, send me an email (confidence inspiring, that). Vyatta doesnt yet have that feature implemented. So I decided to use GRE tunnels, and bridge them to an ethernet interface. Since this tunnel was going to run over the public internet, I encrypted/encapsulated the whole thing using a standard site-to-site IPSEC tunnel.font-family:” times=””>The relevant configs look like this (note that this is not the entire config, and all IPline-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>First, define the bridge interface. Not that STP (Spanning Tree Protocol) is disabled. You likely want this disabled unless youline-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>The ETH0 interface is on the server VLAN (or port group if you are using standard ESXi vSwitches) this is the VLAN that you are bridging to the DR site.line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>The GRE tunnel is also bridged, and also doesnt have an IP address. The encapsulation of GRE-bridge is the same as GRE (IP protocol 47), but the gre-bridgeline-height:
normal”>line-height:
normal”>This stuff is all important for your security posture, but is not relevant to the tunneling or bridging, so Iline-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”> line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”> line-height:
normal”>line-height:
normal”>line-height:
normal”>line-height:
normal”>mso-bidi-font-family:Symbol”> Note that the peer IP is the public / NATmso-bidi-font-family:Symbol”>
IDs have to be created for each end – these routers use XAUTH when you define a pre-shared key, so to avoid having them use the FQDN, itmso-bidi-font-family:Symbol”>
The traffic match for encryption is defined by the source prefix+destination prefix+protocol. In our case, its the management IP of the customer router AND the matching IP on the cloud router AND GREmso-bidi-font-family:Symbol”>mso-bidi-font-family:Symbol”> Take some care in defining the pre-shared key. If a word occurs on your corporate website, facebook page, or linkedin (or in a dictionary), its a bad choice, LEET-speak or no.mso-bidi-font-family:Symbol”> We set both ends to initiate, which enables both init and respond. This allows either end to start the tunnel

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

CyberSafe-WP-Admin