Microsoft Azure Site-to-Site VPN with SonicWALL OS- Part 2 Configure SonicWALL OS VPN Policy

Introduction

In my previous article “Microsoft Azure Site-to-Site VPN with SonicWALL OS”, we discussed about the configuration needed for creating Site-to-Site VPN in Azure portal using “Resource Group”. It can also be created in classic portal. Nevertheless, the process may be insignificantly different in classic mode and thus needs few additional steps. In our example we have mentioned VPN type as “Route-based” at the time of creating VPN gateway. However, we could have configured with “Policy-based” because our device is compatible for all type of VPN but some of the device does not work with “Route-based”. So, the question may arise what is the significant difference between “Policy” and “Route” based VPN.

Policy Based VPN is a configuration in which a specific VPN tunnel is referenced in a policy whose action is set as tunnel.

Route Based VPN is a configuration, in which the policy does not reference a specific VPN tunnel. Instead, a VPN tunnel is indirectly referenced by a route that points to a specific tunnel interface.

Following here we will see the entire procedure of configuring VPN policy and the procedure needed to establish tunnel between onpremises and Azure.

A. Creating VPN Policy

To create a VPN policy for making connection between onpremsies to Azure.

– Here is our Sonicwall Admin Portal. Login with admin credential and navigate to VPN and Settings.

– Under the VPN Policies click on ADD.

Microsoft Azure Site-to-Site VPN with SonicWALL OS

– In the VPN Policy, navigate to General. Here, the specifications are needed about VPN gateway created in Azure. Refer to Part I of this series.

– Policy Type: Tunnel Interface

– Authentication Method: IKE PSK

– IPSec Primary Gateway: The public IP of the VPN Gateway (VPNGw1)

– IKE Authentication: we will use the shared key which was given at the time of creating Azure VPN gateway. And in our scenario, we have only used the IPv4 address and that must be specified in Local IKE ID and Peer IKE ID.

– Navigate to Proposals, in IKE (Phase 1) proposal, we must keep in mind about the IKE Version because “Policy-Based” is compatible with IKEv1 and “Route-Based” is compatible with IKEv2.

– Diffie-Hellman Group (DH Group), public key cryptographic is used by most of the organization. Group 2 consists 1024-bit key and it is compatible with both type of VPN.

– SA Lifetime for the IKE (Phase 1) will be set to 28800 seconds by defaults.

– In the IPsec (Phase 2) proposal, Encapsulating Security Payload (ESP) protocol provides authentication, integrity. ESP also provides message/payloads encryption.

– SA Lifetime, has been given 3600 seconds as recommended by SonicWALL. Route-Based supports maximum 27,000 seconds

– In the Advanced, we will select the wan interface by which the VPN traffic will go out, in case multiple ISPs are terminated in VPN device. You should choose the appropriate WAN interface to which the VPN tunnel will be binded.

B. Creating Address Object

– The address object needs to be created based on the subnet used in Azure. In our case, the “172.16.0.0/16” subnet was created as gateway subnet in Azure. Navigate to the Network | Address Objects and create the address object.

C. Adding Route Policy

The last and final requirement is to create a routing policy to route packet to proper destination

You are now a step behind completing the VPN tunnel that will correctly route traffic. Once the VPN policy is define, you need to create the necessary Routing Policies that I have described in my next Article – Microsoft Azure Site-to-Site VPN with SonicWALL OS – Part 3 – Configure VPN policies and Routing

Microsoft Azure and SonicWALL STS – Part 1 – Configure Azure Resource Group

Microsoft Azure and SonicWALL STS – Part 2 – Configure SonicWALL OS VPN policy

Microsoft Azure and SonicWALL STS – Part 3 – Configure VPN policies and Routing