Problem using Routing Policy tab on Netgear R7000 with FreshTomato v. 2020.6


eibgrad

LI Guru
Member
Ahh, so you just got unlucky. The DNS server from the VPN provider just happened to not be able to resolve that one particular domain name. Pretty unusual.

Those happen to be Cloudflare DNS servers, but you can use anything you like (e.g., Google, 8.8.8.8, 8.8.4.4, Quad9, 9.9.9.9).

The only problem w/ the current solution is that those Cloudflare DNS servers will be routed over the WAN, NOT the VPN, due to the fact PBR is active. Technically, anytime you're not using the ISP's DNS servers, it NOT considered a DNS leak. But for me personally, I don't like to route DNS over the WAN at all, because it can still be examined, redirected, etc., by the ISP.

You could force those DNS servers over the VPN if it wasn't for the following bug/flaw in the OpenVPN client which (coincidentally) I just reported.


Btw, instead of those changes, you could use Cloudflare all the time by adding the following to DNSMasq.

Code:
no-resolv
server=1.1.1.1
server=1.0.0.1

Then change "Accept DNS configuration" on the OpenVPN client to Disabled. The no-resolv tells DNSMasq to ignore the ISP's DNS servers and only use those listed herein.
 

eibgrad

LI Guru
Member
In this second setup the DNS servers would be routed over the VPN?

NO. The problem remains. As long as you're using PBR, that takes the router itself off the VPN (that's just how it works). And normally DNS *would* be routed over the VPN because the DNS server(s) pushed by the VPN provider would typically be in the same private IP space as the tunnel (iow, that's the only known path to those DNS servers). However, as we now know, that server was unable to resolve that one domain name. And if you insist on having that domain name routed over the VPN using PBR, you're forced to use alternate DNS servers, like Cloudflare. But Cloudflare will default to the WAN. If it wasn't for that bug/flaw, you could add route directives to force them over the VPN as well.

So either way, you have the same results; Cloudflare (or whatever public DNS servers you choose) will always be routed over the WAN w/ PBR active. All I'm suggesting is, given the overall situation, it might make more sense to just have Cloudflare (or whatever) become your default DNS all the time, whether or not the OpenVPN client is or isn't active, by forgoing those changes to the OpenVPN client (which I did just to see if that was the problem) and make your changes directly to DNSMasq.

Not a necessity. If you want to stick w/ those changes I made to the OpenVPN client, it'll work too.

Of course, if access to whatismyipaddress.com is NOT vital, and this was just a fluke, you can ignore this one case and go on w/ the original configuration. Seems to me you could just as well use, say, ipchicken.com in lieu of whatismyipaddress.com if you only intend to use it to confirm whether PBR is working. And now you'd be back to having DNS routed over the VPN.
 

Monkeywrench

Network Noob
Member
Hi,
Today I took a little time to experiment with this. Overall the Routing Policy tab is NOT working like it should.
  • No, I didn't just get unlucky. The DNS server from the VPN provider also isn't able to resolve any other domain name (www.whatismyip-address.com, ipchicken.com, www.speedtest.net).
  • Only after I run the "nslookup domain.name" command can I find the corresponding IP address in the hash table and then the domain is going through the VPN.
  • Once a policy is enabled this way I can't disable it by simply unchecking it in the Routing Policy table. In order to get the hash table back to where it didn't include an unchecked policy, I had to reboot the router. That pared the hash table back to only the selected policies.
So, the implementation of the "Routing Policy" tab isn't working for me. With the commands you gave me I can get some of the functionality but not the user friendly experience the tab promises.
 

pedro311

Addicted to LI
Member
You have to restart ovpn client to make it work.
From the very beginning, when the PBR was introduced, there was no restart of ovpn after clicking save on it (and I still forget to add it there).
 

eibgrad

LI Guru
Member
Hi,
Today I took a little time to experiment with this. Overall the Routing Policy tab is NOT working like it should.
  • No, I didn't just get unlucky. The DNS server from the VPN provider also isn't able to resolve any other domain name (www.whatismyip-address.com, ipchicken.com, www.speedtest.net).
  • Only after I run the "nslookup domain.name" command can I find the corresponding IP address in the hash table and then the domain is going through the VPN.
  • Once a policy is enabled this way I can't disable it by simply unchecking it in the Routing Policy table. In order to get the hash table back to where it didn't include an unchecked policy, I had to reboot the router. That pared the hash table back to only the selected policies.
So, the implementation of the "Routing Policy" tab isn't working for me. With the commands you gave me I can get some of the functionality but not the user friendly experience the tab promises.

Op, the FT/Shibby implementation of PBR based on domain names is flawed, and imo, it should either be reworked or eliminated. It was a cool idea, esp. a few years ago, but nowadays, as implemented, it lacks sufficient reliability.

The fundamental problem w/ domain names is that everything hinges on DNSMasq resolving those domain names. But there are numerous reasons that might not happen (in no particular order).

1. You're using some other *local* DNS server besides DNSMasq (e.g., pihole).
2. You have clients configured w/ public DNS servers.
3. The client has previously cached the results of name resolution for those domain names, or perhaps has them in a local hosts file.
4. The browser may be handling its own name resolution (that's a big one).

That's what makes domain names different for PBR purposes than explicit IPs (source or destination). In the latter case, you know w/ certainty it will work. With domain names, it's always an open question. It depends on several configuration issues, some of which you don't control.

The proper way to handle domain names (or destination IPs for that matter) is via static routes (and one of the reasons I'm trying to get that bug/flaw regarding route directives w/ PBR fixed!). But that requires YOU to resolve those domain names prior to starting the OpenVPN client and add them as route directives to the Custom Config field. And depending on the number of domain names, and the number of IPs associated w/ those domain names, it can be a daunting task. For one or two domain names, most of which return only one IP, and rarely change, it's probably workable.

Bottom line, I strongly urge users to NOT use the domain name feature in PBR, esp. w/ browsers now doing their own name resolution. It will prove increasingly frustrating, esp. since most users don't understand how domain name support is implemented, and therefore it will remain mysterious to them why it seems so unreliable. As I said, personally, I think it should be reworked or scraped. PBR isn't about destination IPs anyway; it's meant for other criteria, like source IP, protocol, ports, etc.
 
Last edited:

Monkeywrench

Network Noob
Member
Thanks again for your generosity in sharing your expertise.

I'll follow your advice and hold off on using the PBR tab for the moment. Hopefully, it will be reworked to make it function more reliably.

Just one more question. This exchange has piqued my interest in the subject. Could you point out a good reference guide to the commands/instructions that can be added to the Custom Configuration field.

Thanks.
 

fork29

New Member
Member
Hi guys, a few words from me here as well.
I tried to route a quite a few domains over my VPN provider using PBR. I had also troubles. It did not work reliably. I was using pyload for my downloads. When downloading from different sites, they sometimes went through VPN and sometimes not.

I wanted to analyze the situation, but did not know how to monitor my clients connections. When I used "trace route" on clients everything looked ok. But tomato -> tools -> system commands "trace route" ignored openVPN route and went into WAN.

I guess it could improve on making this feature more transparent. Like a tool / command to check a domain after it was applied in PBR. And a help to fire fight issues that prevent PBR to work.

my 2cents
 

eibgrad

LI Guru
Member
Nothing has to be "reworked" there as it works as it should.

It works as *designed*. In fact, it works *perfectly* as designed. But the design is flawed. If PBR is claiming to route those domains over the VPN, and it doesn't for any reason, even if it works as designed, it doesn't work as it should. The fact that I or anyone else would have to detail the underlying implementation in order to explain its unreliability, doesn't speak well of this feature. Not unless we're prepared to warn the user about its unreliability, and perhaps various means to mitigate the situation. And if not, I'd be more inclined to get rid of it, because for me, what good is a cool feature if I can't trust it? And if the user insists on using domain names, *they* have to take responsibility for ensuring those domain names are resolved prior to the use of PBR. It may not be what the user wants to hear, but at least PBR then works w/ 100% reliability.

In fairness, the use of domain names, in *any* context, has always been (and will always be) problematic, whether it's in the creation of firewall rules, routing commands, or PBR. But it's usually not obvious to users why that is the case. And I expect things to get even worse as browsers have now decided to implement their own name resolution.
 

Top