How Can I Setup Site To Site VPN With IKE2?

Introduction, Deployment Scenario, and IKEv2 vs. IKEv1 Discussion

IKEv2 Proposal Type is the most modern, reliable solution. 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. 

NOTE: This article is for when both sites with Firewalls have static, public IP addresses on their WANs. IKEv2 is far superior and it is very easy to change to it compared to IKEv1

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 method with IKEv2 can handle any scenario for which Aggressive Mode is often used.

Compared to the Main and Aggressive Modes of IKEv1, IKEv2 is more efficient and more reliable in general.

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.

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.