SMA 8200v Azure/AWS Deployment Guidelines

Accessing Azure and AWS Images

• Azure
  The SMA1000 8200v image is available from the Azure Marketplace:
  
  1. Go to the Azure Marketplace at https://azuremarketplace.microsoft.com
  2. Search for SMA 8200v in the Search bar.
  After obtaining the image, installation can proceed as outlined in the SMA and CMS on Azure Getting Started Guide.
  
  
• AWS
  On AWS the SMA 8200v AMI is available as a public Shared AMI.
  . The steps needed to launch a new instance of this AMI from the EC2 Console are as follows:
  1. Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
  2. In the navigation pane, choose AMIs.
  3. In the first filter, choose Public images. Then enter the search string "SMA 8200v" in the Search bar.
  4. There should be two Public images found: "SonicWall SMA 8200v Virtual Appliance 12.4.0-xxxxx" and "SonicWall SMA 8200v Virtual Appliance 12.4.0-xxxxx (tiny)". Use the full image for most purposes, including full scale trials and production deployments. Use the "(tiny)" image only for very small trials and demos. It is sharply constrained in order to be compatible with AWS free tier accounts.
  5. Select the desired image and choose Launch.
  From this point installation can proceed as outlined in the SMA and CMS on AWS Getting Started Guide.

Choosing Cloud Instance Types
The following recommendations are intended as guidelines to instance type selection, derived from extensive lab-based testing and analysis. It is extremely important to keep in mind that inherent differences in deployment-specific usage patterns may necessitate use of larger, or smaller, instance types than these general-purpose recommendations.

Azure

AWS

NOTE: * c5 usage and performance numbers are valid ONLY with the April HF AMI (available by the end of April 2020).

Specifying Tunnel Address Pools

In traditional datacenter deployments the most commonly used method for managing tunnel client addressing is "Routed address pool (Dynamic)", a DHCP-driven model. However, DHCP restrictions enforced by both AWS and Azure within their virtual infrastructures cause this model to be impractical to use in those environments. This leaves two primary alternatives for use in cloud deployments - "Routed address pools (Static)" and "Translated address pools (Source NAT)". For most cloud deployments the first option, Static pools, is the recommended method.

Routed address pool (Static)

Static address pools allow for every tunnel client to have an independent and distinct IP address, and this type of supports very large pool sizes in order to maximize the number of tunnels that a particular instance will support. As when running in ESXi and HyperV deployments this is expected to support up to 5000 concurrent clients in most cases.

For compatibility with Azure and AWS environments this type of addressing will require additional configuration within the specific cloud environment as outlined here:

• Azure
  Please perform the following in the Azure management portal:
  1. IP forwarding must be manually enabled on the appliance's virtual network interface.
  2. A route table must be created and attached to the appliance's subnet, and a route must be added with an address prefix equal to the static IP pool range, and the next hop set to the appliance's private IP address.
     
     
• AWS
  Please perform the following in the AWS management portal:
  1. Disable Src/Dest Check on the appliance's ENI adapter.
  2. Create a VPC for the tunnel IP pool. The CIDR range must not overlap with the VPC the appliance is in.
  3. Create a VPC peering connection between the appliance's VPC and the tunnel pool VPC.
  4. Add a route to appliance VPC's route table with the destination set to the static IP pool CIDR and the target as the appliance's ENI adapter.
  Note that there is an AWS-imposed pricing caveat to be aware of - the required VPC peering connection has a data transfer charge of $0.01/GB for data transfer in both directions. 

Translated address pool (Source NAT)

While convenient to set up and manage, Source NAT pools have several attributes that limit suitability except in very specific situations.

Due to inherent NAT limitations (source port exhaustion) the number of individual user tunnels that can be managed is limited to approximately 500 or fewer per SMA appliance. Deployments that expect to scale beyond this number will need to be designed as a GTO cluster with the count of managed nodes derived from the expected user count. It is recommended to target a 250-300 max tunnels per appliance in order to leave a safe margin.
There may be applications that do not run well in NAT environments.

On both AWS and Azure the NAT IP address must be explicitly added to the appliance's virtual network interface as follows:

• Azure
  https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-addresses#add-ip-addresses
  
  
• AWS
  https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/MultipleIP.html#assignIP-existing 

Additional Note for both AWS and Azure for access thru the SMA to the Public Internet: 

If it is desired to allow remote users to access the internet thru a cloud based SMA, there is an additional configuration required.  There is a limitation in the NAT capability of these cloud platforms in relation to IP address pools.

- Routed Address Pool Static: 

With a Routed Address Pool Static you must use a separate device, like an NSv, to handle the NAT translations.  The cloud-based services to not inherently provide this ability. 

- Source Route NAT Pool:

You can use the same approach for a Source Route NAT pool, or you can add a second IP address to the instance for that Source Route NAT IP and add an AWS Elastic IP (or the Azure equivalent) to that second instance IP. This allows the cloud service to handle the NAT for the single Pool IP address.

The typical scaling concerns for Source Route NAT applies in this case. With larger numbers of users this does not scale.