Adding a Tunnel Interface

To add a Tunnel Interface:
1
Navigate to VPN > Settings.
2
In the VPN Policies section, click the Add button. The VPN Policy dialog displays.

NOTE: This procedure is based on using an IKE authentication method. If Manual Key is selected for Authentication Method, all IKE options are removed.
3
On the General tab, select the policy type as Tunnel Interface. The IPsec Secondary Gateway name or Address option and the Network tab are removed.

4
Click the Proposals tab.

5
Configure the IKE (Phase 1) Proposal and IPsec (Phase 2) Proposal options for the tunnel negotiation.
6
Click the Advanced tab to configure the advanced properties for the Tunnel Interface. By default, Enable Keep Alive is enabled. This is to establish the tunnel with remote gateway proactively.

7
Disable IPsec Anti-Replay - Disables anti-replay, which is a form of partial sequence integrity that detects the arrival of duplicate IP datagrams (within a constrained window).
Enable Windows Networking (NetBIOS) Broadcast - Allows access to remote network resources by browsing the Windows® Network Neighborhood.
Enable Multicast - Allows multicast traffic through the VPN tunnel.
Permit Acceleration - Enables redirection of traffic matching this policy to the WAN Acceleration (WXA) appliance
Management via this SA - Allows remote users to log in to manage the SonicWall through the VPN tunnel. Select one or more: HTTP, HTTPS, SSH, SNMP.
User login via this SA - Allows users to login using the SA. Select one or both: HTTP (this may be dimmed and, therefore, unavailable) or HTTPS.
VPN Policy bound to - Sets the interface the Tunnel Interface is bound to. This is Interface X1 by default. Two different WAN interfaces cannot be selected from the VPN Policy bound to drop-down menu if the VPN Gateway IP address is the same for both.
8
If IKEv2 Mode was selected on the Proposals tab, configure the IKEv2 Settings:
The Do not send trigger packet during IKE SA negotiation check box is not selected by default and should be selected only when required for interoperability if the peer cannot handle trigger packets.

The term Trigger Packet refers to the use of initial Traffic Selector payloads populated with the IP addresses from the packet that caused SA negotiation to begin. It is recommended practice to include Trigger Packets to assist the IKEv2 Responder in selecting the correct protected IP address ranges from its Security Policy Database. Not all implementations support this feature, so it may be appropriate to disable the inclusion of Trigger Packets to some IKE peers.

Accept Hash & URL Certificate Type – The firewall sends an HTTP_CERT_LOOKUP_SUPPORTED message to the peer device. If the peer device replies by sending a “Hash and URL of X.509c” certificate, the firewall can authenticate and establish a tunnel between the two devices.
Send Hash & URL Certificate Type – The firewall, on receiving an HTTP_CERT_LOOKUP_SUPPORTED message, sends a "Hash and URL of X.509c” certificate to the requestor.

When this option is selected, enter the URL for a certificate in the Certificate URL field.

Select these options if your devices can send and process hash and certificate URLs instead of the certificates themselves. Using these options reduces the size of the messages exchanged.

In a VPN, two peer firewalls (FW1 and FW2) negotiate a tunnel. From the perspective of FW1, FW2 is the remote gateway and vice versa.

9