x3mRouting x3mRouting ~ Selective Routing for Asuswrt-Merlin Firmware

[maghuro]

@Xentrk tried your detailed instruction in your blog to set DNS with VPN to work with diversion. It works great. I have only one minor thing that I couldn't figure out. Main DNS is 1.1.1.1 connecting under WAN to the closest servers to my location. When activating VPN at different geo-location, the client uses the same location as the main DNS, not the closest to VPN server. Is it possible to allow the VPN client to use the nearest Cloudflare server to the VPN location instead of the same location of WAN DNS? I'm thinking this could effect browsing performance and I could be wrong. Thank you.

Just manually add a rule on VPN client (policy rules) to force everything TO 1.0.0.0/8 to go through VPN.

 

[maxsteel]

Just manually add a rule on VPN client (policy rules) to force everything TO 1.0.0.0/8 to go through VPN.

thank, with dns configuration as disabled or exclusive?

 

[maghuro]

thank, with dns configuration as disabled or exclusive?

Disabled. Otherwise it'll use vpn DNS instead of cloudflare.

 

[maxsteel]

Disabled. Otherwise it'll use vpn DNS instead of cloudflare.

just tried it. it doesn't change to DNS server close to the VPN server.

 

[maghuro]

just tried it. it doesn't change to DNS server close to the VPN server.

Screenshot please

 

[maxsteel]

Screenshot please

 

[maghuro]

View attachment 24775

You have to put it on destination instead of source.

 

[Marin]

You have to put it on destination instead of source.

the destination IP should be what he has. The source IP can be 0.0.0.0:

Policy Rule Routing on Asuswrt-Merlin Firmware - x3mtek Blog Site

Create policy rule routing rules that define which clients, or which destinations, should be routed through either the WAN interface or OpenVPN Client tunnel usng Asuswrt-Merlin firmware.

x3mtek.com

 

[maxsteel]

You have to put it on destination instead of source.

the destination IP should be what he has. The source IP can be 0.0.0.0:

Policy Rule Routing on Asuswrt-Merlin Firmware - x3mtek Blog Site

Create policy rule routing rules that define which clients, or which destinations, should be routed through either the WAN interface or OpenVPN Client tunnel usng Asuswrt-Merlin firmware.

x3mtek.com

Thank you guys it is working now. Much appreciated !

 

[Xentrk]

@maghuro This appears to be a much better solution than entering the dhcp-option DNS x.x.x.x work around solution in the Custom Config section as it allows the DNS to be in the same geo location as the VPN server one is connected to. I also tested by entering the 1.1.1.1 and 1.0.0.1 in the policy routing table rather than using the CIDR notation. The solution works when Accept DNS Configuration is set to Strict, Relaxed and Disabled. The Exclusive setting still works as expected even with the DNS entries in the Policy Routing table. Excellent suggestion!

 

[maghuro]

@maghuro This appears to be a much better solution than entering the dhcp-option DNS x.x.x.x work around solution in the Custom Config section as it allows the DNS to be in the same geo location as the VPN server one is connected to. I also tested by entering the 1.1.1.1 and 1.0.0.1 in the policy routing table rather than using the CIDR notation. The solution works when Accept DNS Configuration is set to Strict, Relaxed and Disabled. The Exclusive setting still works as expected even with the DNS entries in the Policy Routing table. Excellent suggestion!

Thanks
Regarding the CIDR, I suggested that to also handle the 1.0.0.2 and 1.0.0.3 that cloudflare is implementing.
As the 1.0.0.0/8 is reserved to them, better use it for future-proof

 

[Xentrk]

Note to those who are using the LAN Client Routing and/or x3mRouting OpenVPN Client Screen Option

There are some changes to OpenVPN in the 384.19 test builds that only impacts those using the x3mRouting OpenVPN Client Screen to create the routing rules for IPSETs. See [Test] Asuswrt-Merlin 384.19 - OpenVPN test builds for more information. I will need to create a 384.19 branch of x3mRouting for those who use the x3mRouting OpenVPN Client Screen and make changes to the x3mRouting version of vpnrouting.sh and updown-client.sh files. For now, please hold off on implementing the 384.19 test build until I can complete the required changes.

 

[raven-au]

Are you using one of TG's shared VPN servers or a Dedicated IP? The later is required for Amazon Prime.

I'm using a dedicated IP.
But, because (presumably) I signed up in Australia, I need to bypass the VPN for Prime.
Disney+ and Netflix work fine.

There is one issue with the GUI method you should be aware of. A firewall restart (service restart_firewall) will clear the routing rules.

Run the command below to see the routing rules for the IPSET lists:

iptables -nvL PREROUTING -t mangle --line

If you are using a dedicated IP and you get blocked, run the command above to see if the routing rules are still in effect. You can also check the system log file to see if a firewall restart event occurred. This problem does not exist when you specify the source and destination interface to the x3mRouting script. The current work around is to add the command below to /jffs/scripts/nat-start file on the last line. The "1" is the VPN client number. 1,2,3,4 and 5 are valid values.

service restart_vpnclient1

/jffs/scripts/nat-start will run at boot or after a firewall event. Restarting the VPN Client will recreate the missing routing rules.

Right, I thought it was something like that although I wasn't sure because a client restart (from the GUI) didn't always work.
I'll try the workaround you recommend when I get a chance.

Thanks.

 

[Marin]

Thanks
Regarding the CIDR, I suggested that to also handle the 1.0.0.2 and 1.0.0.3 that cloudflare is implementing.
As the 1.0.0.0/8 is reserved to them, better use it for future-proof

Thanks @maghuro! Now I see the rationale for doing what you recommended. I will go ahead and make the same change for my VPN clients!

 

[maxsteel]

Thanks
Regarding the CIDR, I suggested that to also handle the 1.0.0.2 and 1.0.0.3 that cloudflare is implementing.
As the 1.0.0.0/8 is reserved to them, better use it for future-proof

Thank you. All clients assigned to use VPN now work with DNS geo-location perfectly. I noticed one problem only that other clients -not assigned to either WAN or VPN- uses the DNS geo-location of VPN even when they have ISP IP. Any idea round that?

 

[maghuro]

Thank you. All clients assigned to use VPN now work with DNS geo-location perfectly. I noticed one problem only that other clients -not assigned to either WAN or VPN- uses the DNS geo-location of VPN even when they have ISP IP. Any idea round that?

I think unfortunately that's a problem you must live with if you want to route DNS through vpn ...

What you can do (I don't know if it works, I'm just thinking) is:
On DNS filter, set mode to custom 1.
On custom 1 insert the DNS, let's say cloudflare 1.1.1.1, that you want.
In this case, it isn't needed DNS being routed through vpn policy rules...

Theoretically each client will connect to cloudflare nearest anycast PoP. Because, instead of clients getting router ip, they'll get cloudflare ip.
However, afaik, this solution will break things like diversion, nextdns app, etc etc... Everything that relies on clients having router ip as DNS.
Please try if it works.

 

[maxsteel]

I think unfortunately that's a problem you must live with if you want to route DNS through vpn ...

What you can do (I don't know if it works, I'm just thinking) is:
On DNS filter, set mode to custom 1.
On custom 1 insert the DNS, let's say cloudflare 1.1.1.1, that you want.
In this case, it isn't needed DNS being routed through vpn policy rules...

Theoretically each client will connect to cloudflare nearest anycast PoP. Because, instead of clients getting router ip, they'll get cloudflare ip.
However, afaik, this solution will break things like diversion, nextdns app, etc etc... Everything that relies on clients having router ip as DNS.
Please try if it works.

Worked splendidly but unfortunately diversion has been switched off so I will route VPN DNS to every client to get it enabled. Thank you

 

[Luizlp10]

Note to those who are using the LAN Client Routing and/or x3mRouting OpenVPN Client Screen Option

There are some changes to OpenVPN in the 384.19 test builds that only impacts those using the x3mRouting OpenVPN Client Screen to create the routing rules for IPSETs. See [Test] Asuswrt-Merlin 384.19 - OpenVPN test builds for more information. I will need to create a 384.19 branch of x3mRouting for those who use the x3mRouting OpenVPN Client Screen and make changes to the x3mRouting version of vpnrouting.sh and updown-client.sh files. For now, please hold off on implementing the 384.19 test build until I can complete the required changes.

I will give it time to unravel fully and stick to the configuration I have with x3mRouting. I've manage to install and successfully use all "major" scripts except for FreshJrQoS while bypassing my VPN to access NETFLIX and GLOBO domains with your script. Not that I don't trust RMerlin's work but I have a bandwith hungry family to please. Do you think that the way we users interact with x3mRouting will be afected by this change on Merlin's side?

 

[Marin]

Worked splendidly but unfortunately diversion has been switched off so I will route VPN DNS to every client to get it enabled. Thank you

What DNS servers did you use on the WAN tab?

 

[maxsteel]

What DNS servers did you use on the WAN tab?