Business VPN Setup: Policy vs Route-Based with SonicWall Solutions

Compare policy-based vs route-based SonicWall business VPN setups, including routing, traffic control, scalability, and more.
Business VPN Setup: Policy vs Route-Based with SonicWall Solutions

It isn’t so uncommon for organizations to be managing multiple office networks with the help of business VPNs. However, not all VPN solutions are the same, and it’s important that you’re working with a proper setup for the sake of efficiency and safety.

For example, SonicWall security services give you the option of both policy-based and route-based approaches with your VPNs. This article highlights the difference between these two approaches and can help you get aligned with the right VPN strategy for your company.

Key Takeaways:

  • Policy-based VPNs use defined traffic selectors to control network communication
  • Route-based VPNs use tunnel interfaces and routing rules to direct traffic
  • Adding subnets to policy-based VPNs requires additional configuration
  • Route-based VPNs offer greater flexibility as networks expand
  • Matching PSK, proposals, and feature settings helps ensure compatible SonicWall VPN endpoints

Policy-Based vs Route-Based Business VPN

The gist of policy-based and route-based configurations, when it comes to business VPN solutions, is that they both connect separate networks. In the same vein, they handle traffic through the VPN in different ways. It’s that distinction that I want to talk about here. A policy-based configuration defines the networks allowed to communicate as part of your VPN setup. 

On the flip side, a route-based configuration separates the VPN tunnels from specific networks. This is done by using a tunnel interface, in addition to routing rules. Without a grasp on what makes policy-based and route-based VPNs unique, you’ll have a hard time choosing the right configuration for your network.

"The difference isn’t the firewall, it’s which kind of VPN you build."

What is a Policy-Based VPN?

It helps to know that a policy-based VPN determines which traffic can use a VPN tunnel through predefined network information. At the same time, you’ll want to dig a little deeper to see how this correlates to your real-world network demands.

Here are several core details about policy-based VPNs you’ll want to keep in mind:

  • Tunnel Behavior: Only traffic matching the configured selectors can use the VPN tunnel
  • Network Expansion: Adding a subnet requires modifying the VPN configuration
  • Admin: VPN’s traffic selectors need to be maintained and configurations updated on your firewalls when connected networks or subnets change
  • Scalability: Can require more  ongoing configurations as the number of connected networks increases

Expanding on some of the admin notes; if you add another subnet, that network will need to be incorporated into your VPN configuration. Moreover, the corresponding configuration needs to be updated on the firewalls connecting more than one location.

What is a Route-Based VPN for Business?

For route-based VPNs, they separate the VPN tunnel from the specific networks that need to communicate. On top of that, the VPN creates a dedicated tunnel interface for the connection.

Here are a few comparable highlights about route-based network VPN:

  • Tunnel Behavior: Creates a tunnel interface that operates separately from specific network conditions
  • Network Expansion: New subnets can be incorporated through routing without modifying the VPN tunnel
  • Admin: Manage traffic paths through routing rules
  • Scalability: Separating routing from the tunnel can simplify adding networks as your environment grows

An additional detail I like to point out is that adding a new subnet can be handled by creating or updating a route, rather than changing the VPN tunnel itself. For those working in IT, OSPF or BGP can also create routes automatically. If you’re going to navigate this effectively, then you’ll need to know how to build both a policy-based and route-based VPN.

Building a Policy-Based VPN with SonicWall

There are a handful of steps you’ll have to go through to set up policy-based corporate VPNs through SonicWall. While they aren’t complicated by any means, it’s pretty crucial that you don’t miss a step here to avoid issues down the road.

Follow these steps to build a policy-based VPN with SonicWall:

  1. Open your SonicWall VPN settings and create a new VPN connection
  2. Create a descriptive name using a consistent naming scheme
  3. Add the WAN IP/domain and optional secondary WAN for failover
  4. Enter the PSK and local IKE ID
  5. Choose the network connected to the VPN
  6. Create an address object, such as 10.0.20.0/24, for example
  7. Add address objects to an address group when needed
  8. Set the VPN encryption and proposal options
  9. Configure Keep Alive and Windows networking/NetBIOS as needed
  10. Use matching PSK, proposals, and feature settings for remote firewalls

It might seem like a lot on paper, but it’s actually pretty straightforward. In addition to this, it doesn’t hurt to have a route-based VPN step-by-step in your back pocket as you navigate your decision-making.

Building a Route-Based VPN with SonicWall

While you’re bound to see a few similarities in the setup process for a route-based VPN, the differences will definitely stand out. Sure, it seems like a lot of steps to keep track of, but that’s why I’m putting these resources together so you can reference them any time you like.

Check out how to build a route-based VPN with SonicWall below:

  1. Go to the SonicWall VPN configuration settings and add a new VPN
  2. Change the VPN type to Tunnel Interface
  3. Enter the local WAN address and remote peer WAN address
  4. Enter the shared secret/PSK and local IKE ID
  5. Review and configure the VPN encryption and available features
  6. Create the tunnel interface without defining network objects in the VPN configuration
  7. Navigate to Policy, then Routing Rules, to configure how traffic uses the tunnel
  8. Define the source, destination, service, tunnel interface, and metric
  9. Use the SMB example to route file-sharing traffic through the tunnel
  10. Ensure the peer uses matching PSK, proposals, feature settings, and corresponding endpoint information

For the most part, that’s really all there is to it. At the same time, many organizations look to professional managed services to help handle things like network configurations and ongoing management.

Outside of the setup process, as a business owner or team lead for IT, it’s crucial to think about scalability as well. Thankfully, this also comes with a simple comparison that can help you understand what kind of scalability you’re getting out of the two.

Business VPN Scalability: Policy-Based vs Route-Based

Remember, policy-based VPNs associate the tunnel with specific networks through defined traffic selectors. With route-based VPNs, these separate the tunnel from individual networks by using a tunnel interface and routing rules. For a quick comparison of what scalability can look like for both sides here, take a look at the table below.

FactorPolicy-Based VPNRoute-Based VPN
Network DefinitionUses defined source and destination networks as traffic selectorsUses a tunnel interface with routing rules for networks
Adding SubnetsRequires updating the VPN configurationRequires adding a route instead
Tunnel StructureDirectly tied to defined network trafficOperates separately from specific networks
Traffic ControlTraffic must match configured networksRouting rules determine which traffic uses the tunnel
Network ExpansionNew networks require additional VPN configurationNew networks can be added through routing

The main scalability difference in here is how traffic is associated with the VPN connection. It’s either directly through network definitions or separately through routing.

Let’s Wrap This Up

Both policy-based and route-based business VPNs can connect separate business networks through SonicWall security services. However, route-based VPNs can provide greater flexibility as networks grow. With policy-based VPNs, if you’re dealing with relatively defined networks, then they aren’t a bad way to go. 

You can also avoid any technical hurdles or bottlenecks with scalability by working alongside our team at Firewalls.com. Let’s hop into a call and work on your SonicWall VPN setup together. Feel free to learn more on your own by checking out our video below, which offers additional insight on policy-based vs route-based VPNs.

Frequently Asked Questions

A policy-based VPN can make sense when the networks using the connection are relatively fixed and clearly defined.

The new subnet needs to be incorporated into the VPN configuration, with corresponding changes made on the connected firewalls

The tunnel interface separates the VPN connection from individual networks, allowing routing rules to determine which traffic uses it.

Yes, SonicWall routing rules can specify a service, such as SMB, to control which traffic travels through the tunnel.

The PSK, VPN proposals, and applicable feature settings need to match between the connected firewalls for the configuration to work properly.

Share:

More Posts

Share:

More Posts