How Can I Setup Site To Site VPN With IKE2 In SonicOS?

10/22/2020 238 People found this article helpful 90,917 Views

Description

Introduction, Deployment Scenario, and IKEv2 vs. IKEv1 Discussion

This IKEv2 Proposal Type is the most modern, reliable solution for this. The IKEv2 option has been our default for almost a decade. All Gen5, Gen6, Gen6.5 SonicWall firewall models can be configured for Site To Site VPNs with IKEv2, from the lower TZ models up through all higher models: NSA, NSa, SuperMassive, and NSsp product lines. It is also supported on almost any IKE VPN appliance from other major vendors. VPN with IKEv2 is specified in IETF RFC 7296, and was adopted as a standard. It also has many improvements in areas such as security, NAT-Traversal, EAP, and VOIP. See this SonicWall KB article about IKEv2 advantages, and this Wikipedia article on IKE / IKEv2.

This article is for when both sites with Firewalls have static, public IP addresses on their WANs. For many years, SonicWall customers have chosen the older IKEv1 method Main Mode for this deployment scenario, but IKEv2 is far superior and it is very easy to change to it.

See the below related article for the scenario when one firewall has a dynamic, or RFC-1918 private IP address on its WAN, and thus the other site, which is static, cannot point to it using the IPSec Gateway field. This other method with IKEv2 can handle any scenario for which Aggressive Mode is often used.

Here are more general points about this example VPN, detailed below. It is a very simple, split-tunnel VPN, which uses only the two X0 LANs configured on the firewalls as network objects. In contrast, SonicOS also supports many other forms of VPN, including ones which route all Internet traffic onto the VPN to the other side, as well as other Types (Tunnel Interface) and Authentication Methods (IKE Using 3rd Party Certificates; SonicWall Auto-Provisioning Client; SonicWall Auto-Provisioning Server; Manual Key).

This IKEv2 option is the default type of IKE Proposal when a new VPN Policy is added. The IKEv2 Protocol has been our default for almost a decade, going back to very old versions of SonicOS 5.x.x.x . Compared to the Main and Aggressive Modes of IKEv1, IKEv2 is more efficient and more reliable in general. It is just as easy to use, especially when both firewalls have static, public IP addresses on their WANs so that both sides can specify an IPSec Gateway.

I've included images from a new, blank IKEv2 VPN Policy window from a Gen6.5 model on newly released SonicOS 6.5.4.6, and from an old Gen5 versions SonicOS 5.8.1.13, web-posted in July 2013, almost 7 years ago. NOTE: In these example images, I first specified an IP address in the IPSec Gateway field, so that all of the configurable options under IKEv2 are shown. When no IPSec Gateway is specified, the options for the IKE Proposal [DH Group; Encryption; Authentication; Life Time (seconds)] are not configurable except for in the VPN > Advanced setting called "IKEv2 Dynamic Client Proposal," which applies to all VPN Policies lacking the IPSec Gateway. Though that is not used in the method for this article, it is important to explain the behavior of the UI which relates to it.

Cause

Two sites with Firewalls have static, public IP addresses on their WANs, and there is a need for the internal networks behind them to have a secure connection.

Resolution

Step-By-Step Instructions:

Basics about the two firewalls involved in the VPN

NSA-5600 on SonicOS 6.5.4.5: X1 WAN Interface IP address: 10.61.34.65 /28 ;
X0 LAN Interface IP address: 192.168.56.56 /24 ; X0 Subnet 192.168.56.0 /24

NSa-5650 on SonicOS 6.5.4.5: X1 WAN Interface IP address: 10.61.134.10 /28 ;
X0 LAN Interface IP address: 192.168.156.50 /22 ; X0 Subnet 192.168.156.0 /22
Identify which objects, on both sides (internal networks or hosts / ranges, or groups of these), are going to participate in the VPN.

EXAMPLE: T
wo network objects are used, cross-matched on the two firewalls:
NSA-5600: Local - X0 Subnet 192.168.56.0 /24 ; Remote - NSa-5650 X0 Subnet 192.168.156.0 /22
NSa-5650: Local - X0 Subnet 192.168.156.0 /22 ; Remote - NSA-5600 X0 Subnet 192.168.56.0 /24
Create, on each firewall, new network address objects, in zone VPN, for the remote internal networks or hosts / ranges, or groups on the other side.

A local network address object (X0 Subnet) was auto-created by SonicOS when the X0 LAN interfaces on both firewalls were configured. See the four images below.
Create VPN Policies on both firewalls, including the below settings.

To start, navigate to Manage | VPN | Base Settings, Add (Contemporary Mode), or VPN | Settings, Add (Classic Mode).
General Tab:
Type: "Site to Site";
Authentication Method: "IKE Using Preshared Key"
Specify Name,
IPSec Gateway,
Shared Secret (all other fields are optional for this scenario).

TIP: You can copy / paste the Shared Secret between the two VPN Policy windows. It accepts all ASCII characters. You can toggle the "Mask Shared Secret" checkbox and it will auto-fill the "Confirm Shared Secret" field.

Two VPN Policy windows spring up when the Add button is clicked on two firewall's web management sessions; the General settings can be typed or copied in on each.
Network Tab:
Choose an object for both of these on each firewall:
(Choose local network from list;
Choose destination network from list).
Proposals Tab:
Use Exchange: IKEv2 and choose items for IKE Proposal [DH Group; Encryption; Authentication; Life Time (seconds)] and for IPSec IKE Proposal [Encryption; Authentication; Life Time (seconds)]. In this case I've chosen stronger types of DH Group, Encryption, and Authentication and shorter lifetimes than default. Perfect Forward Secrecy is optional. When enabled, a "DH Group" option is available there. See the below two images.
Advanced Tab:
At least one side should have the "Enable Keep Alive" checkbox turned on. In this example, the NSa-5600 (Sitka) side has it on. Having both can lead to issues if one of the firewalls has a lot of VPN Policies. Other common features used are "Enable Windows Networking (NetBIOS) Broadcast" and Management via this SA: (HTTPS). The VPN is bound to Zone WAN by default, but it can be configured to specific network interfaces if needed (usually WAN interfaces). See the below two images.
If the above steps are done without error, and without enabling other advanced features, both firewalls will have an active VPN Policy (with a green dot indicator) and traffic can flow between the two LANs.
Traffic can flow because of automated bidirectional access rules between the LAN and VPN zones. The access rules have mouseovers with comments saying they were auto created for (VPN Policy Name). The rules' appearance is not specific to IKEv2 or IKEv1 types.

The two VM hosts behind the two firewalls involved in the VPN are able to send traffic to each other on ICMP, TCP and UDP, and to the opposite firewall's X0 interface, for ping, HTTPS Management and other management services such as SSH if enabled on the VPN Policy.
The VM on NSA-5600 X0 Subnet 192.168.56.200 is pinging 192.168.158.243 and is able to HTTPS manage the other firewall on its X0 IP of 192.168.156.50 .
The VM on NSa-5650 X0 Subnet 192.168.158.243 is pinging 192.168.56.200 and is able to HTTPS manage the other firewall on its X0 IP of 192.168.56.56 .
The VM on NSA-5600 X0 Subnet 192.168.56.200 is able to use RDP client to access the other VM 192.168.158.243, and the opposite works. The pings in both directions are still going, at a rate of over 1 MBps.