Route Based VPN

A policy-based approach forces the VPN policy configuration to include the network topology configuration. This makes it difficult to configure and maintain the VPN policy with a constantly changing network topology.

With the Route Based VPN approach, network topology configuration is removed from the VPN policy configuration. The VPN policy configuration creates a Tunnel Interface between two end points. Static or Dynamic routes can then be added to the Tunnel Interface. The Route Based VPN approach moves network configuration from the VPN policy configuration to Static or Dynamic Route configuration.

Not only does Route Based VPN make configuring and maintaining the VPN policy easier, a major advantage of the Route Based VPN feature is that it provides flexibility on how traffic is routed. With this feature, you can now define multiple paths for overlapping networks over a clear or redundant VPN.

Topics:

Terminology

 

VPN Tunnel Policy

A policy configured without a local/remote protected network. When sending a packet out, SonicOS does not need to look up any tunnel policy.

VPN Tunnel Interface

An interface created on the Network > Interface page and bound to a tunnel policy. The interface is configured as the egress interface of a route entry or a SonicOS App that actively sends out packets such as Net Monitor Policy, Syslog policy. When SonicOS sends a packet out over the VPN Tunnel, logically it's the same as sending the packet over a physical interface, except the packet is encrypted.

Using Route Based VPN

Route Based VPN configuration is a two-step process:

1
2

The Tunnel Interface is created when a Policy of type Tunnel Interface is added for the remote gateway. The Tunnel Interface must be bound to a physical interface, and the IP address of that physical interface is used as the source address of the tunneled packet.

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

3
On the General tab, select the policy type as Tunnel Interface.

The IPsec Secondary Gateway name or Address field on the General tab and the Network tab are removed.

4
5
Click the Proposals tab.

6
Configure the IKE (Phase 1) Proposal and IPSec (Phase 2) Proposal options for tunnel negotiation.
7
Click the Advanced tab to configure the advanced properties for the Tunnel Interface. By default, Enable Keep Alive is enabled.

8
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 firewall through the VPN tunnel. Select one or more: HTTPS, SSH, SNMP.
User login via this SA - Allows users to login using the SA. Select either or both: HTTP or HTTPS.
VPN Policy bound to - Sets the interface the Tunnel Interface is bound to. This is Interface X1 by default.
IMPORTANT: 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.
9
If IKEv2 Mode was selected on the Proposals tab, configure the IKEv2 Settings:
The Do not send trigger packet during IKE SA negotiation checkbox 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.

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.

10
Creating a Static Route for Tunnel Interface

After you have successfully added a Tunnel Interface, you may then create a Static Route.

To create a Static Route for a Tunnel Interface:
1
Navigate to Network > Routing > Route Policies.
2
Click the Add button. The Add Route Policy dialogue appears for adding Static Route.
3
Select a tunnel interface from the Interface drop-down menu, which lists all available tunnel interfaces.
NOTE: If the Auto-add Access Rule option is selected, firewall rules are automatically added and traffic is allowed between the configured networks using tunnel interface.
4
5

Route Entries for Different Network Segments

After a tunnel interface is created, multiple route entries can be configured to use the same tunnel interface for different networks. This provides a mechanism to modify the network topology without making any changes to the tunnel interface.