What's new

Solved Do I need any VPN Director policy rules?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

DTS

Regular Contributor
I see a lot of references to "strict policy routing" or "policy based routing". For example, this post:

I set the vpn to use exclusive dns and strict policy routing.

Referring to the Merlin Wiki page Policy based routing · RMerl/asuswrt-merlin.ng Wiki leaves me unsure about policy settings with firmware 386.3_2 or later.

Currently I have this setting:

Redirect Internet traffic through tunnel: Yes (all)

None of my VPN clients are configured for VPN Director (Policy Rules). I want all traffic to go over the VPN, I want to use a killswitch. And I want to failover from VPN provider #1 to VPN provider #2.

Do I need to use VPN Director (Policy Rules) at all?
 
If you're NOT being selective about which LAN clients are routed over the VPN, but just want everything routed over the VPN, there's no need for policy rules. That's why there's a "Yes (all)" option.
 
  • Like
Reactions: DTS
P.S. I should add. Sometimes there can be an advantage to using policy rules, even when you want all LAN clients routed over the VPN.

One of the subtle differences between using policy rules vs. Yes (all) is that the former (unlike the latter) takes the router itself off the VPN. That can be important in two instances. When you need to access services offered by the router over the WAN while it has an active OpenVPN client (e.g., OpenVPN server). The other when you're supporting multiple, concurrent OpenVPN clients. In the latter case, if you don't use policy rules, then subsequent OpenVPN clients will likely be routed through any existing OpenVPN client, which is generally NOT recommended. It's far better to use policy rules in that case and specify the whole LAN (192.168.1.0/24), even if you don't need/want to be selective. So now you never end up routing one OpenVPN client through the other.

I thought you might find this particularly useful information given your other recent posts.
 
Last edited:
P.S. I should add. ...

I thought you might find this particularly useful information given your other recent posts.
Yes, thank you. Maybe I do need to use policy rules. What is the best post to reference for using policy rules the way I'm trying to set things up?

All I have done in my troubleshooting tonight is get myself more confused. So shifting to another approach like policy rules sounds good.
 
Yes, thank you. Maybe I do need to use policy rules. What is the best post to reference for using policy rules the way I'm trying to set things up?

All I have done in my troubleshooting tonight is get myself more confused. So shifting to another approach like policy rules sounds good.

I don't know of any specific other post, but I would recommend that you use policy rules for both OpenVPN clients and specify the entire LAN (e.g., 192.168.1.0/24) in each case. Then only enable the kill switch for the secondary/backup OpenVPN client (note, lower numbered OpenVPN clients take precedence over higher-numbered OpenVPN clients). That way, if the primary OpenVPN client fails, it falls through to the secondary/backup OpenVPN client. If that fails, internet access is denied. All the while, make sure you do NOT create any IP conflicts on the tunnels established by both OpenVPN clients. See how far that gets you.

Note, you might as well use the built-in kill switch unless and until you become convinced it's not working for some reason.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top