It is important to understand how connectivity works when using Failover in rCloud. Armed with this knowledge you can successfully bring up your Failover network and machines in the rCloud and decide how you will get your users connected.
Failover Connectivity Explained
When you start a machine with Failover Connectivity you are provided with the following configuration and options:
- Machines running with Failover connectivity start behind their own virtual firewall, just like any other machine running in rCloud.
- A single (one), dedicated, static, public IP address is provided for the duration the machine(s) are running.
- Typically the IP network (subnet mask and gateway) for the secure LAN in the rCloud replicates the protected network. This can be changed at the time of restore or later, as long as the change is made before the first machine is started with Failover Connectivity.
By default the following standard TCP ports will be forwarded to the first machine started with Failover Connectivity.
- 25 - SMTP
- 80 - HTTP
- 110 - POP
- 143 - IMAP
- 443 - HTTPS
- 444 - SBS 2003/SharePoint
- 987 - SBS 2008/SharePoint
- 3389 - RDP
The standard set of TCP ports listed above may also be configured to forward to other machines on the Failover LAN.
- PPTP and L2TP VPN traffic can optionally be passed through the virtual firewall to the first machine started with Failover connectivity. This enables inbound VPN connections to be terminated on this machine running in the rCloud, thus providing access to the secure Failover network in the rCloud.
- Additional port forwarding for non standard ports can be requested by contacting Accelerite Support.
- Full outbound internet access is provided for all ports and protocols.
See the Start a Machine with Failover Connectivity for a step by step guide to enable and configure Failover Connectivity.
Given the following functionality there are 2 possible connectivity methods that can be used to facilitate a recovery and ultimately get users connected to their data and applications.
- Inbound Connectivity
- Outbound Connectivity
This is by far the most common approach. Users connect in to the rCloud to access their data and applications. This can be achieved in a number of ways
- VPN: In this case Routing and Remote Access (RRAS) is setup on the first Windows 2003 or Windows 2008 machine that is started with Failover Connectivity. NOTE: GRE and/or L2TP passthrough must are enabled when the machine is started. See the Start a machine with Failover Connectivity Section for details. Users will be able to make inbound VPN (PPTP or L2TP) connections using the Windows VPN client for full network access. There are a couple of advantages to this approach:
- The VPN client is built in to all Windows and most Mac systems.
- Users will authenticate with their own Domain credentials.
- Terminal/Citrix Server: In this case, if available, a terminal or Citrix server is restored as part of the recovery. Port forwarding can be configured to publish the server directly to the Internet or users can connect once they have established a VPN connection.
- Direct access: This method would involve enabling specific inbound ports to directly publish services. This would most commonly be web services (e.g. Outlook Web Access, SharePoint etc) but any TCP or UDP port can be forwarded.
The diagram below illustrates this approach
With this approach the machine(s) are connected back in to the production network via outbound VPN connections. This approach can be used when a single or subset of the machines at a site are unavailable. Users will typically be working from their office as usual. The steps to achieve this will vary depending on the setup at the production site but will be along these lines:
- There is a VPN endpoint at the production site, at the network edge or on a server
- The appropriate VPN client is installed and configured on the recovered machine(s) running in the rCloud
- A VPN is established outbound from the rCloud to the production site, thus connecting the machine(s) back to the production LAN
NOTE: Using Failover Connectivity is not necessarily required to make this approach work as no inbound connections are needed.
There are a couple of important considerations and changes that may need to be made to make this approach work
- The Failover IP network will need to be different from that of the production network in order for routing to work
- The recovered server that is connected to the LAN via VPN may have a different IP on its VPN adapter than the original server. DNS may need to be updated manually to reflect this.
The diagram below illustrates this approach