SMA 8200v Azure/AWS Deployment Guidelines

03/31/2020 3 1639

DESCRIPTION:

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

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.
The current management console displays a prominent warning suggesting that this type of address pool be limited to 100 users or less. This warning is overly strident and plan is in place to modify the code to display a more appropriate informational message when running on AWS or Azure instances. But in this initial release the warning is always present.
There may be applications that do not run well in NAT environments.