Advanced Network Sandbox for Azure

Jump to:

Overview

How to enable the Network Sandbox

How does Network Sandbox work?

Ingress traffic management

When you may want to consider not using Arpio's Network Sandbox

Allowing some outbound access via Network Firewall

Remote access to VMs behind the Firewall

Monitoring Blocked Traffic

Firewall Whitelist FAQs

Overview

When it's time to test your disaster recovery setup, you will need to consider the implications of launching a full replica of your environment. 

Launching a test using Arpio's test capability will launch your recovery resources in isolation in your recovery environment, while your production environment continues to serve traffic.  However, you need to ensure that the workloads under test do not interact in any conflicting manner with the production workloads.

Unless you have configured network connectivity between your primary environment and your recovery environment, your recovery environment systems cannot interact directly with your primary environment.  But, if your workload actively connects outbound to resources on the internet, your recovery environment could interact with those same resources in ways that could impact your production services. 

To eliminate this risk, Arpio can isolate your recovery environment and block outbound access to the internet.  Inbound access is still permitted, so you can still test your systems by connecting through load balancers, bastion hosts, or other publicly exposed resources. To do this, you will need to enable the Network Sandbox capability before running your failover test.

How to enable the Network Sandbox

To enable the Network Sandbox feature, begin by initiating test recovery for your Arpio application by clicking the “Test” button in the Arpio console. 

Then, click the checkbox for "Enable Network Sandbox" in the Test Recovery dialog in Arpio.

As a proactive measure when using Network Sandbox for multiple Arpio applications, you are restricted to applications that have the same region pairs (primary and recovery locations). Azure resources can have networking dependencies on one another within the same region. If a collection of Arpio applications does have dependencies, we will attempt to discover them and fail them over together across Arpio applications on restore. 

How does Network Sandbox work?

When you enable this option, Arpio will attempt to add a new public IP and Azure Firewall instance in the recovery environment in front of any Azure virtual networks. 

This will leverage a new subnet and private IP for the Azure Firewall. We’ll also attempt to add/update UDRs (user defined routes) to properly ensure that all outbound traffic is routed to the firewall’s private IP within the vNet. 

The following diagram illustrates the Arpio Network Sandbox approach: 

When you conclude your test, all these changes are removed and your vNet will return to its original state, matching the primary location’s settings.

Ingress traffic management

While all egress traffic is routed through the firewall and filtered, ingress traffic to Application Gateways and Load Balancers is still allowed when the sandbox is in place to allow for testing.

For Application Gateways, Arpio follows Microsoft's guidance for running Application Gateways and Firewalls in parallel.

For Load Balancers, Arpio follows this approach where an additional public IP is allocated for each load balancer, and DNAT rules are created to map from the firewall's public IP to the load balancer's IP.  This requires tests to hit the firewall's IP instead of the load balancer's IP when the network sandbox is enabled.

When you may want to consider not using Arpio's Network Sandbox

A common situation is for cloud networks to have their default route pointed to an on-prem location which then manages outbound access back to the internet. In this type of situation, it may be easier to implement your own approach to creating a network sandbox for your application instead of trying to reconfigure the environment that Arpio would establish.

In situations such as these, with complex relationships between multiple networks, please feel free to reach out to us regarding your specific needs and we will work with you to try and find an optimal solution. 

Allowing some outbound access via Network Firewall

If your application relies on sending traffic outside your internal network to function, Arpio allows you to add a combination of either domains or public CIDRs to an allowlist.  These are then translated into Network Firewall rules to allow the specified traffic to flow out to the internet.

To enable some outbound access, initiate test recovery for your Arpio application and enable the network sandbox. On this same page you will have the option to to fill out the allowed domains and/or CIDR blocks. 

Refer to the Firewall Whitelist FAQ below for tips on using this capability.

Remote access to VMs behind the Firewall

The blocking of all outbound traffic will also have an impact on your ability to RDP/SSH into any VMs behind the firewall. While you can try to manually adjust the routes and port requirements to enable this access, we recommend you instead leverage Azure Bastion.

If your application already includes a bastion host, Arpio will recover this host along with the rest of your application and it should continue to function normally in the recovery region. If you don’t already have a bastion host, you can create one in the recovery resource group after you have started the test and it will be automatically cleaned up by Arpio after the recovery test is completed. 

Monitoring Blocked Traffic

The Azure Firewall(s) that Arpio creates for filtering traffic are configured to send connection blocking events to Azure Monitor.  This can help you identify additional domains or CIDR blocks that may need to be added to the allowlist in order for your workloads to function properly during a failover test. A list of commonly blocked domains can be found here. 

Arpio makes these events directly available within the Arpio console by clicking on the "See most recent events" link at the top of the application page after the test has started. 

For more advanced analysis of the block events, you can also view the events directly within Azure Monitor log analytics by querying for events in the AZFWNetworkRule and AZFWApplicationRule categories. 

Firewall Whitelist FAQs

• Arpio will remember your sandbox settings, including allow lists. So the next time you want to test your recovery, the values will be pre-filled for you.
• You can specify multiple CIDR and domains by comma separating the list of values.
• To allow all domains with a common suffix, prepend a '.' to the beginning of the domain.  For example, to allow traffic to the family of Azure Storage Account services (as well as static web hosting), use ".core.windows.net" as the allowed domain.
• Only IPv4 CIDR blocks are currently supported.
  • Arpio will apply the CIDR blocks you specify directly to your security groups, without modifying, de-duplicating, or other complex logic.
  • To specify a single IP, you add the /32 suffix to the CIDR.
• If you have an application in RECOVERY TEST, and you would like to initiate a Test for a second application that shares the same target environment, the existing sandbox settings for the previously restored application cannot be changed with the second recovery test. This is to prevent conflicting, or surprising results in your recovery environment. In order to change the settings, you will need to conclude the test in the first application.
  • If you want to test multiple applications with the same recovery environment, we recommend initiating both tests at the same time, with the same network sandbox settings.
• Like the network sandbox itself, the outbound access settings are compared with your existing security group rules. Arpio will only allow access to ports and IP addresses that allow outbound access in your primary environment.
• If outbound traffic is allowed to any service via a private endpoint, the traffic will flow over Azure’s private network and not use the firewall’s public route. Otherwise, the traffic will traverse the public internet to the appropriate public endpoint for that service.