Introduction to Policy Rule Routing
When configuring your router to use an OpenVPN Client on Asuswrt-Merlin firmware, you can define policy rules that define which clients, or which destinations, should be routed through either the WAN or VPN interface. Policy Rule Routing on Asuswrt-Merlin firmware is also referred to as Selective Routing.
Enabling Policy Rules
To enable the Policy Rule feature in Asuswrt-Merlin firmware, set “Redirect Internet traffic” to “Policy Rules” or “Policy Rules (Strict)” in the OpenVPN Client Screen. Policy Rules (Srtict) mode will take additional steps to ensure there aren’t any extra routes that could potentially bypass the VPN tunnel by only allowing routes that specifically target the VPN tunnel’s network interface. The Policy Rules (Srtict) mode is the preferred setting. However, this will interfere with any route you may have manually configured on your WAN interface, which is why it is listed as a separate option.
Entering Policy Rules
Once you enable Policy Rules, a new section will appear below, where you can add routing rules. The “Source IP” is a local LAN Client device, such as a laptop or mobile phone. “Destination” is a remote server on the Internet. The “Destination” field can be left empty, or set to 0.0.0.0 to signify any IP address. You can also specify a whole subnet in CIDR notation. For example, 188.8.131.52/30.
The “Iface” field, which is short for Interface, lets you determine if matching traffic should be sent through the VPN tunnel or through your regular Internet WAN access. This allows you to define exceptions. WAN rules are processed before the VPN rules.
By default, all traffic will go through the WAN. What you define with a VPN “iface” will be routed through the VPN. Use the WAN “iface” to configure exceptions to VPN rules. For example, you use CIDR notation and configure a /24 subnet to be routed through the VPN, but want one IP within that /24 subnet to be routed through the WAN instead.
You cannot configure a policy in the OpenVPN Client screen that will be based on a port number. Only single IP addresses or IP address using CIDR notation are supported.
For those who prefer to route all LAN traffic to the VPN, enabling the “Policy Rules” or “Policy Rules (Strict)” setting enables the option to “Block routed clients if tunnel goes down” to be displayed. Enabling this option will allow you to block LAN traffic from traversing to the WAN interface if the VPN tunnel goes down.
OpenVPN Client Priorities
The Asuswrt-Firmware supports up to five OpenVPN Clients running concurrently. OpenVPN Client 1 has a higher priority than OpenVPN Client 2. OpenVPN Client 2 has a higher priority than OpenVPN Client 3 and so on. From my experience, If you have more than one OpenVPN client active, you must configure the router’s IP address to use the WAN interface. If you are using more than one OpenVPN Client, you only have to add the router’s IP address entry in the OpenVPN Client screen with the highest priority. For most people, this will be the OpenVPN Client 1 screen.
Defining the router’s IP address to use the WAN interface and the priorities of the OpenVPN Clients is the first place to look if you experience issues with Policy Rules or traffic is not going where you expect it to.
“Accept DNS Configuration” set to “Exclusive”
When combined with Policy Rules based routing, all clients configured to use the VPN will use the DNS servers provided by the VPN tunnel. LAN Clients configured to go through the WAN will use the DNS configured in the WAN Settings Screen.
The disadvantage of setting “Accept DNS configuration” to “Exclusive” is that DNSMASQ will be bypassed since the VPN tunnel will exclusively use the DNS of the VPN Provider. The popular Diversion ad blocker program, written for the Asuswrt-Merlin firmware, will not work since Diversion requires the features of DNSMASQ. Diversion will work over the VPN tunnel when “Accept DNS configuration” is set to “Exclusive” and Policy Rules are disabled by setting “Redirect Internet Traffic” to “All”.
There are two options available if you want the OpenVPN client to use DNSMASQ when using Policy Rules. This is done by setting “Accept DNS Configuration” to either “Strict” or “Disabled”.
“Accept DNS Configuration” set to “Strict”
If you set Accept DNS Configuration to “Strict”, you must then specify the DNS server for the VPN tunnel to use by adding the dhcp-option DNS command in the Custom Configuration section per the example below.
dhcp-option DNS 184.108.40.206
“Accept DNS Configuration” set to “Disabled”
My preferred recommendation is to set “Accept DNS Configuration” to “Disabled” and install Stubby DNS over TLS. Stubby DNS over TLS will encrypt DNS queries for all devices on the network.
Accept DNS Configuration Definitions
For reference, the definition of the Accept DNS Configuration field values are as follows:
- Disabled: DNS servers pushed by VPN provided DNS server are ignored.
- Relaxed: DNS servers pushed by VPN provided DNS server are prepended to the current list of DNS servers, of which any can be used.
- Strict: DNS servers pushed by the VPN provided DNS server are prepended to the current list of DNS servers, which are used in order. Existing DNS servers are only used if VPN provided ones don’t respond.
- Exclusive: Only the pushed VPN provided DNS servers are used.
Policy Rule Examples
Route All Traffic through the VPN and Block Routed Clients If Tunnel Goes Down
This is an alternative to setting “Redirect Internet Traffic” to “All Traffic”. To enable this feature, enable Policy Rules or Policy Rules (Strict) and set “Block routed clients if tunnel goes down” to “Yes”. With this configuration, all traffic is routed to the VPN. If the VPN connection goes down, the traffic will not be able to traverse through the WAN interface and all LAN clients will lose internet connectivity.
LAN_IPs 192.168.1.0/24 0.0.0.0 VPN
Configure LAN to use the VPN interface and the Router to use WAN interface
A common configuration where you want your entire LAN to go through the VPN, but not the router itself.
LAN_IPs 192.168.1.0/24 0.0.0.0 VPN
Router 192.168.1.1 0.0.0.0 WAN
For my use case, I find the entry for the router is required in the OpenVPN Client 1 Screen when using more than one OpenVPN Client instance and have multiple rules routing traffic through more than one VPN interface and other traffic through the WAN interface.
Select an IP address for each LAN Client you want to route through the VPN – All other traffic traverses to the WAN interface
In the example, two LAN Clients traverse through the VPN interface and all other LAN Clients traverse through the WAN interface.
Laptop 192.168.1.50 0.0.0.0 VPN
iPad 192.168.1.51 0.0.0.0 VPN
Select a range of IP addresses using CIDR notation for LAN clients to traverse through the VPN and all other traffic through the WAN interface
You can use the CIDR range 192.168.1.80/28 which are address’s between 192.168.1.80-192.168.95. In this example IP address 192.168.1.80 through 192.168.1.95 will traverse through the VPN interface while all other traffic will traverse through the WAN interface.
LAN_IPs 192.168.1.80/28 0.0.0.0 VPN
There are many CIDR calculators available on the internet that can assist you in determining the IP address ranges using CIDR will affect.
Route All LAN Clients to a destination IP Block
Direct all LAN Clients to use the VPN tunnel when accessing an IP block that belongs to Google.
RouteGoogle 0.0.0.0 220.127.116.11/16 VPN
Select a range of IP addresses using CIDR notation for LAN Clients to traverse through the VPN and destination IP address’s to traverse through the WAN interface
In the example below 192.168.1.0/24 is the range for 192.168.1.1 through 192.168.1.254. This rule routes all traffic through the VPN interface. In the second rule, 192.168.1.50 is the LAN IP address for one LAN Client and 18.104.22.168/19 is the CIDR notation for Facebook. All traffic from 192.168.1.50 will use the VPN interface, except for the Facebook traffic, which will get routed to the WAN interface.
LAN 192.168.1.0/24 0.0.0.0 VPN
Laptop 192.168.1.50 22.214.171.124/19 WAN
The Policy Routing functionality available in the Asuswrt-Merlin firmware OpenVPN Client Screen should be able satisfy the use case requirements for most people. However, if you require additional flexibility in your rules, stay tuned for my follow up blog post that will cover Advanced Selective Routing techniques available on Asuswrt-Merlin firmware.
The content on the post was gathered using the references below and from my personal experiences using Asuswrt-Merlin.