policy routing failing to route through vpn.

[ex99125b]

I have been running 184.19 on an AC66U-B1 for a couple of weeks. I have several LAN devices that run on-device Nordvpn clients and have two devices without. I have set up a single OpenVPN client in Merlin with policy routing for the two devices (static IPs) to route through the VPN, all other devices run through to WAN. I have yaz vpnmgr installed but not managing my Openvpn client ( at this time).
EDIT: I have uninstalled vpnmgr to lessen variables, but problem persists.

If I set "Force all traffic..etc" to "no", it works as expected.

If set to "yes" it works as expected.

if, however I set it to "policy rules", either strict or not, no traffic travels through the VPN.

I have read (obsessively) the wiki and all relevant docs, so I have tried about everything I could think of, even re-declaring the default of /24 as "WAN" first and then entering my two exceptions as VPN. Ive tried /24 to VPN, nope. And, yes Ive tried excluding the router from vpn...opposite the example in the wiki. In all cases, Ive been careful to follow the WAN first then VPN evaluation rules. All of my DNS settings are correct and functioning as expected.

Im missing something and its frustrating.

Like I said, the vpn client works great and even leaving the OpenVpn client "on" and "Force all traffic" to "off" work fine together...but policy routing is a no-go.

If anyone has any ideas, Id really appreciate the help. Thanks.

 

[Sobster88]

If you want all traffic to go through WAN except for certain devices, set to Policy Rules Strict and put the IP of your device in the rules. Don’t forget to make a static reservation so set a static IP on the device itself so it will always get the same IP.

 

[ex99125b]

Thank you for the quick response.
I understand "how" to do what I want to do, you correctly pointed out where I started.

The problem is that it isnt working, and all of the things that I listed in my message were things that I tried (unsuccessfully) trying to debug my issue.

 

[eibgrad]

It has to be asked … how do you know FOR SURE these devices are NOT using the VPN? It's not always obvious, particularly if the device provides no direct means for feedback (e.g., Smart TV). Yeah, if it's a PC, laptop, etc., and it's bound to the VPN, then presumably an online IP checker (e.g., ipchicken.com) would provide some indication based on the public IP. But I want to be sure that's what we have here.

FWIW, when I question whether the WAN or VPN is being used, I check w/ connection tracking to see what it says is the network interface being used for any particular transaction.

cat /proc/net/nf_conntrack

There are two pairs of src+dst fields in each record. The most significant for our purposes is the *second* pair, specifically the dst field. That will contain the IP address to which the router is expecting a reply, which you can then map back to its specific network interface using ifconfig. That way you don't need to depend on inference to determine the network interface being used. Connection tracking always tells you the truth.

Correction, dst field, NOT src.

 

[ex99125b]

It has to be asked … how do you know FOR SURE these devices are NOT using the VPN? It's not always obvious, particularly if the device provides no direct means for feedback (e.g., Smart TV). Yeah, if it's a PC, laptop, etc., and it's bound to the VPN, then presumably an online IP checker (e.g., ipchicken.com) would provide some indication based on the public IP. But I want to be sure that's what we have here.

FWIW, when I question whether the WAN or VPN is being used, I check w/ connection tracking to see what it says is the network interface being used for any particular transaction.

cat /proc/net/nf_conntrack

There are two pairs of src+dst fields in each record. The most significant for our purposes is the *second* pair, specifically the src field. That will contain the IP address from which the router is expecting a reply, which you can then map back to its specific network interface using ifconfig. That way you don't need to depend on inference to determine the network interface being used. Connection tracking always tells you the truth.

Thank you for responding!
dnsleaktest and whatsmyip...one device is a kindle which has a sortof-browser and I can access my public ip. The other device is a roku and while its pretty clear when its on/off vpn, I added a laptop to my list of static IPs and started using it in my rules...made it easy to keep checking.
EDIT: no linux box, but tracerout on my mac shows my connection to my public ip as well.

 

[RMerlin]

Make sure your traffic isn't going through IPv6, as the VPN tunnel only handles iPv4 traffic.

 

[ex99125b]

Make sure your traffic isn't going through IPv6, as the VPN tunnel only handles iPv4 traffic.

Thanks for responding. The VPN works fine, it's only the policy routing which doesn't work.

I don't think that I saw anything in the policy routing docs that suggested that it routes through IPv6. I could be wrong, am I misunderstanding?

 

[RMerlin]

Thanks for responding. The VPN works fine, it's only the policy routing which doesn't work.

I don't think that I saw anything in the policy routing docs that suggested that it routes through IPv6. I could be wrong, am I misunderstanding?

It's not the VPN that would be routing through IPv6, it would be your clients. If they try to use an IPv6, then that traffic will not be affected by the VPN rules.

 

[ex99125b]

OK. Then that's not my issue, IPv6 is turned off in my Mac, which is what I'm testing with. Roku and the kindle arent capable of it.

 

[eibgrad]

I'd still be interested in what connection tracking is indicating.

When all else fails, time to dump the relevant data structures (using ssh) and let's actual *see* what the router is doing. Maybe something has gone awry.

ip route
ip route show table ovpnc1
ip rule
ifconfig

P.S. I'm assuming OpenVPN client #1 (ovpnc1).

 

[ex99125b]

OK, I ran all four commands under on my mac with a static ip, under these 3 circumstances with no other changes:
"Force all traffic..." set to YES
"Force all traffic..." set to POLICY RULES (my mac ip set to VPN)
"Force all traffic..." set to NO
and I have attached a text file with the output.
Interestingly, note that my public IP was a vpn server ip under YES **and** NO, but not POLICY...hmmm.
show table didnt want to work

 

[eibgrad]

When configured for PBR, your ip rules do NOT contain any reference to a source IP intended for the VPN.

0:    from all lookup local
32766:    from all lookup main
32767:    from all lookup default

For example, here's a dump of my ip rules when I've configured 192.168.1.7 for the VPN.

0:      from all lookup local
10101:  from 192.168.1.7 lookup ovpnc1
32766:  from all lookup main
32767:  from all lookup default

That suggests to me that perhaps you made a mistake in how you defined the rule. So it just never got added. Make sure you hit the + sign when adding a rule!

 

[ex99125b]

hmmm. these are my settings, statics and one rule for my mac, one rule for my roku (which the GUI keeps changing to YEAR, along with VAN for WAN and TO DO for TUN). I am at a loss. Any idea why when "Force...etc" set to "NO" all traffic still went to vpn?

 

[Sobster88]

Is your DNS settings on the VPN page set to Exclusive?

 

[ex99125b]

Is your DNS settings on the VPN page set to Exclusive?

Yes, here are my settings

 

[eibgrad]

Any idea why when "Force...etc" set to "NO" all traffic still went to vpn?

Well that's a different issue from using PBR.

That "Force..." option is a bit misleading. When the OpenVPN connection is established, it's possible for either the client or server to change the default gateway to the VPN, specifically by using the "redirect-gateway def1" directive. When connected to a commerical OpenVPN provider, they *always* push this directive to the client to FORCE the default gateway to be changed from the WAN to the VPN. When you set "Force..." to NO, all that does is tell the OpenVPN *client* to NOT include that directive. But the fact the server still sends the directive means that all your traffic is routed over the VPN anyway.

As I said, that "Force ..." option is misleading because it leads you to believe that it alone controls whether traffic is routed over the VPN. It doesn't.

IOW, when connected to a commerical OpenVPN provider, using either Yes or No for the "Force..." option has the same effect because in either case the VPN provider's server is still pushing the "redirect-gateway def1" directive to the client.

 

[ex99125b]

Ah, ok. So then I can remove that variable from my error set. Still no PBR though, argh. Ive tried different combinations of turning the client off, rebooting, apply thinking that somethings not sticking...clearly, as you pointed out above in my ip rules, its not. I think you can see from my screenshots above, it *should* work. I think Ive got everything right.

 

[eibgrad]

Ah, ok. So then I can remove that variable from my error set. Still no PBR though, argh. Ive tried different combinations of turning the client off, rebooting, apply thinking that somethings not sticking...clearly, as you pointed out above in my ip rules, its not. I think you can see from my screenshots above, it *should* work. I think Ive got everything right.

As an experiment, try adding the rules manually via ssh, just to confirm that if the rules were placed there by the GUI, it would work.

ip rule add from 192.168.50.183 table ovpnc1 prior 10101
ip rule add from 192.168.50.103 table ovpnc1 prior 10102

But I'm presently at a loss why it's NOT being placed there by the GUI.

 

[ex99125b]

Yeah... Unfortunately my wife is getting antsy about me mucking around on the router with the game minutes away (we're streaming) . I'll try your suggestion in the morning and get back.. Thanks for all the help

 

[ex99125b]

As an experiment, try adding the rules manually via ssh, just to confirm that if the rules were placed there by the GUI, it would work.

ip rule add from 192.168.50.183 table ovpnc1 prior 10101
ip rule add from 192.168.50.103 table ovpnc1 prior 10102

But I'm presently at a loss why it's NOT being placed there by the GUI.

OK, so after entering the rule for .183 and immediately running ip rule I get:

:/tmp/home/root# ip rule add from 192.168.50.183 table ovpnc1 prior 10101

:/tmp/home/root# ip rule
0: from all lookup local
10101: from 192.168.50.183 lookup ovpnc1
32766: from all lookup main
32767: from all lookup default

So, thats good news right? However if I go to the GUI and press "Apply" for *any* changes, the rules get erased and it reverts to no rules. We are on to something but I dont think it is anything good.

EDIT: attached log from "apply" No changes were made to anything other than command line rule entry, I checked the rule, it worked, I then went to GUI ( screenshot above) and hit APPLY.