Exclude website from being routed to VPN (policy based routing)

[bonezy]

Something to be aware of.

With the new VPN Director, a few things have changed. For one thing, the router no longer allows any routing (whether that be a change in the default gateway, or route directives, whether push'd by the server or specified on the client config) to automatically be applied. The router (under the covers) uses the OpenVPN route-noexec directive to force *all* routing to be managed exclusively by the router's scripts (i.e., the ones OpenVPN calls in response to specific events). It is within these scripts where the decision is made if and when to use (or just ignore) any such directives.

As far as I can tell, using the VPN Director, the router will NOT honor any route directives bound to the WAN. Only those bound to the VPN (which iirc, is the exact opposite of the pre-VPN Director firmware). For anything regarding the WAN, you will need to use policy rules instead. Unfortunately that means you need to *manually* resolve any domain names you want routed over the WAN using nslookup, dig, whatever, in order to create those rules (something the use of route directives didn't require).

Thanks a ton for the reply man.
If figures, as I tried following some of your suggestions in older posts regarding similar subjects and nothing seemed to work.

So either I switch to an earlier fw that doesn't use VPN director or I have to go digging with nslookup, right?
Tbh, I don't have the knowledge to do that latter. I tried to follow Xentrk's instructions last night for xm3routing on his github page but got lost in the process and had to uninstall

But because I'd love to figure out a way, out of curiosity I ran a nslookup now to see the results.

The problem is that

a) It constantly gives me other IP's (and from different ranges) so I don't know what to add
b) It show some IPV6 addresses although I have IPV6 disabled. What gives?
b) Even if I figured that out I wouldn't know where to enter these rules in the router menu.

ASUSWRT-Merlin RT-AX88U 386.3_2 Fri Aug 6 21:48:27 UTC 2021
admin@RT-AX88U-8FB0:/tmp/home/root# nslookup netflix.net
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: netflix.net
Address 1: 100.85.59.120
Address 2: 100.82.180.182
Address 3: 100.82.106.206
admin@RT-AX88U-8FB0:/tmp/home/root# nslookup netflix.com
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: netflix.com
Address 1: 3.251.50.149 ec2-3-251-50-149.eu-west-1.compute.amazonaws.com
Address 2: 54.155.178.5 ec2-54-155-178-5.eu-west-1.compute.amazonaws.com
Address 3: 54.74.73.31 ec2-54-74-73-31.eu-west-1.compute.amazonaws.com
Address 4: 2a05:d018:76c:b684:8e48:47c9:84aa:b34d
Address 5: 2a05:d018:76c:b683:f711:f0cf:5cc7:b815
Address 6: 2a05:d018:76c:b685:3b38:679d:2640:1ced
admin@RT-AX88U-8FB0:/tmp/home/root# nslookup youtube.com
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: youtube.com
Address 1: 142.250.181.238 fra16s56-in-f14.1e100.net
Address 2: 2a00:1450:4001:82f::200e fra16s56-in-x0e.1e100.net
admin@RT-AX88U-8FB0:/tmp/home/root# nslookup netflix.com
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: netflix.com
Address 1: 18.200.8.190 ec2-18-200-8-190.eu-west-1.compute.amazonaws.com
Address 2: 54.155.246.232 ec2-54-155-246-232.eu-west-1.compute.amazonaws.com
Address 3: 54.73.148.110 ec2-54-73-148-110.eu-west-1.compute.amazonaws.com
Address 4: 2a05:d018:76c:b684:8ab7:ac02:667b:e863
Address 5: 2a05:d018:76c:b683:a2cd:4240:8669:6d4
Address 6: 2a05:d018:76c:b685:e8ab:afd3:af51:3aed
admin@RT-AX88U-8FB0:/tmp/home/root# nslookup netflix.net
Server: 8.8.8.8
Address 1: 8.8.8.8 dns.google

Name: netflix.net
Address 1: 100.82.106.206
Address 2: 100.82.180.182
Address 3: 100.85.59.120
admin@RT-AX88U-8FB0:/tmp/home/root#

 

[eibgrad]

Just ignore the IPv6 addresses.

Yes, some domain names will constantly change their public IPs, or rotate them for load balancing purposes. You can either add *all* of them as individual rules, or perhaps assume ones that share the same first three octets (x.x.x) are owned by the same entity and add a rule for a class C network. For example, if you see 1.2.3.4, 1.2.3.5, and 1.2.3.6, you can probably safely assume the domain owns all of 1.2.3.x and specify a single rule for 1.2.3.0/24.

Each rule will have one of those IPv4 addresses specified in the Remote IP field and bound to the WAN network interface (Iface).

But for some organizations, esp. something like Netflix, Amazon, etc., even this may prove difficult since it's possible they own literally thousands of IP addresses, and various sub-domains. That's why sometimes it's better to use a solution based on ipset, which I believe is what xm3routing does. But it's a completely separate process for handling routing policy from the VPN Director. I know early on it had some incompatibilites w/ VPN Director. Not sure what it's present status is since I don't use it. I just remember some users having to disable it in order to have VPN Director work correctly.

 

[bonezy]

Just ignore the IPv6 addresses.

Yes, some domain names will constantly change their public IPs, or rotate them for load balancing purposes. You can either add *all* of them as individual rules, or perhaps assume ones that share the same first three octets (x.x.x) are owned by the same entity and add a rule for a class C network. For example, if you see 1.2.3.4, 1.2.3.5, and 1.2.3.6, you can probably safely assume the domain owns all of 1.2.3.x and specify a single rule for 1.2.3.0/24.

Each rule will have one of those IPv4 addresses specified in the Remote IP field and bound to the WAN network interface (Iface).

But for some organizations, esp. something like Netflix, Amazon, etc., even this may prove difficult since it's possible they own literally thousands of IP addresses, and various sub-domains. That's why sometimes it's better to use a solution based on ipset, which I believe is what xm3routing does. But it's a completely separate process for handling routing policy from the VPN Director. I know early on it had some incompatibilites w/ VPN Director. Not sure what it's present status is since I don't use it. I just remember some users having to disable it in order to have VPN Director work correctly.

Yeah, you're right, that's what happened to me. As soon as I added something in xm3routing's menu, it mucked up VPN director and my VPN gave me an error.
Xentrk hasn't been active for ages on the forum, unfortunately, so if I'll only give it a go if I decide to roll back to an older fw. Which is a shame, cause VPN director is kinda handy.

As for the IP's, I figured that much when I saw that I was constantly getting new IP's and sub-domains.
I did try to add the full range with an x and a 0 (/24) last night for the results I got from IPv4 addresses (saw that from one of your older posts) but that will take forever. I wish that I could just add the domain somewhere and get it automatically resolved.

Just outta curiosity, does the x work only on at the end or can I add an x in the third number too? I mean 1.2.x.x/24 instead of 1.2.3.x/24?

Again, many thanks for taking the time to help.
And just FYI, I managed to circumvent the problem I had with the Formula 1 YT channel by switching to a NordVPN server in the Netherlands, so I am currently only looking for a solution to bypass Netflix through the VPN on the devices my wife uses.

 

[eibgrad]

I wish that I could just add the domain somewhere and get it automatically resolved.

That's the power of using ipset. You specify the domain name(s) you want monitored to DNSMasq. Then whenever one of those domains or sub-domains is resolved, the results get added to an ipset hash table. You then create a single rule in the firewall that checks for a match between the contents of the hash table and the current packet's source and/or destination IP, and if it does match, mark the packet for routing over the WAN.

This is a well-known technique that's been around for years. And it's the only efficient means to deal w/ large numbers of domains and IP addresses.

Just outta curiosity, does the x work only on at the end or can I add an x in the third number too? I mean 1.2.x.x/24 instead of 1.2.3.x/24?

You could aggregate IP addresses based on the first two octets (x.x.y.y). But that would be a class B network, and would need to be specified as x.x.0.0/16. But the problem is that given the size of a class B network (64k hosts!), it's highly likely that parts of it are owned by other entities. And so those IPs would be accessed over the WAN as well. Converting to a class C network is generally more reasonable since we're only talking about a max of 256 hosts.

 

[eibgrad]

I threw together a quick and dirty script to implement the necessary changes to route any specific set of domains (and their sub-domains) to the WAN, based on the use of ipset.

merlin-ovpn-lan2wan-by-domain.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

It creates two files. The first modifies DNSMasq to force all name resolution for specific domains (and their sub-domains) to populate the ipset hash table named lan2wan. The second (a bash script) creates the ipset hash table, marks packets in the PREROUTING chain of the mangle table whenever it finds a match between the destination IP in the current packet under examination and the contents of the hash table, and adds an ip rule to route those to the main routing table *before* any VPN Director based policy rules.

I included ipchicken.com only for verification purposes. If you attempt to access that website, it should return the public IP of your WAN/ISP. If it does, then you at least know everything has been configured correctly.

The tricky part is dealing w/ marking packets. As a general rule, I prefer to avoid this technique because there's always the possibility of generating conflicts w/ other parts of the system that also use marks (e.g., QoS). And since there's only *one* field used to mark packets, and I can't know each and every part of the system that may attempt to use marks, and the values of those marks, it's a bit of a gamble whether adding my own mark(s) will work, or work reliably. As a precaution, packets will NOT be marked if any existing marks are detected. Of course, I don't recommend using any other features KNOWN to use marks at the same time (e.g., QoS).

At the very least, it demonstrates how you typically solve this type of problem. It's always going to be more reliable if implemented as part of the installed firmware, since the developers would be far more aware of any potential conflicts in the use of marks. But as a third-party script, it's the best I can do for now.

Note, I don't know if the netflix domain names I included are comprehensive. I just grabbed them from another source. But it's a simple matter to add other domains as you may find necessary. Also, realize you can add multiple ipset directives to DNSMasq using the same ipset hash table, which increases readability.

Installation only requires that you copy/paste the script into the terminal window of an ssh session on the router (or you can use curl, see below), then reboot. It will NOT overwrite any existing files of the same name (including its own). You must also have "JFFS custom scripts and configs" enabled under Administration->System.

curl -kLs pastebin.com/raw/9jHRA6DG | tr -d '\r' | sh

If necessary, you can edit either file using the nano editor.

nano /jffs/configs/dnsmasq.conf.add
nano /jffs/scripts/firewall-start

Despite all the caveats, I still thought it was worth a shot.

 

[eibgrad]

P.S. Something else to make note of here.

The use of ipset *assumes* the client is actually using DNSMasq on the router! Wasn't very many years ago when having to make that statement wasn't necessary. But we now have other options besides Do53, including DoT, DoH, and clients that outright *ignore* your preferred DNS server (i.e., the router's DNS server) and choose to use some public DNS server (e.g., 8.8.8.8). You can also run into problems w/ devices bound to the VPN w/ "Exclusive", since that option, by definition, bypasses DNSMasq on the router! You may have to create an exception for that device using a DNS filter that supersedes it and directs it back to the router.

DNS has become incredibly messing in recent years, and (imo) far too complicated for the average user. There are just too many ways to fall into these various traps and NOT have things work the way you want/expect.

 

[bonezy]

Wow, what can I say? :bow
Many, many thanks for this, hope I can get it to work

I have JFFS custom scripts and configs enabled. I think it was in one of @L&LD 's guides I followed when setting up my router from scratch with amtm, entware, diversion, etc.
As far as VPN settings are concerned, both ExpressVPN and NordVPN are set to exclusive, don't know why I set it like that instead of strict. I think it was because I had problems with DNS leaks perhaps and the apps I run on my AppleTV (Hulu, HBO, etc.)

Does that mean that the script will not work?

Re DNS filters, I have no idea what to do, the setting is off atm in Lan-DNSFilter.
These are my Wan Dns settings, I don't know if they are relevant. If I remember correctly, I set them after reading this post here.

 

[eibgrad]

IMO, the primary advantage of using Exclusive for the VPN is that it forces name resolution of the domain, and subsequent access to the domain, to be performed over the *same* network interface, whether the client is bound to the WAN, or bound to VPN using the VPN Director. IOW…

Those bound to WAN are also bound to the WAN for DNS.
Those bound to VPN are also bound to the VPN for DNS.

That, in and of itself, sometimes eliminates strange behavior compared to a situation where name resolution and subsequent access to the domain occur over *different* network interfaces.

So keep that in mind as we proceed.

So presently you're also using DoT. From a security/privacy perspective, there's really no value in using Exclusive on the VPN (other than what I stated above). Those queries can NOT be seen nor otherwise manipulated by your ISP. So if you change the VPN from Exclusive to Disabled, then as long as you didn't experience any other problems from having VPN clients also use DoT, then at least *all* your DNS queries would be run through DNSMasq. And the results of name resolution would be placed in the hash table for the domains specified in the ipset directives.

At least that's where I would start. It might require some time to evaluate the changes to see if problems do arise, then make adjustments. But one way or another, it's never going to work unless you can be assured your VPN clients are being forced through DNSMasq. And the use of Exclusive definitely bypasses DNSMasq.

P.S. As I said before, just be wary of any rogue clients that might be ignoring the DNS settings from your DHCP server (presumably the LAN ip of your router). It might be a good idea to use a Global DNS filter (set to Router) to force them back to the router for DNS.

 

[bonezy]

Thank you for that, I think I get the (very) general gist of it

The thing is that when I switch to disabled on the NordVPN client, the Formula 1 YT is blocked again
I checked my IP and it shows a Dutch IP in both cases, but the DNS leak tests are different.

vs this with Exclusive

As I had written in a previous post, I had managed to circumvent the problem I had with the Formula 1 YT channel by switching to a NordVPN server in the Netherlands. It doesn't work with other servers.
I assume that the DNS issue won't be a problem for Netflix after we run the script of course, as it will be routed through the wan interface.
The problem will be that then I will have to include YT in the script for everything to run smoothly, no?

 

[eibgrad]

Well here's an example of where you might be running into a conflict because your are NOT using the DNS server(s) provided by the VPN. IOW, you're damned if you, and damned if you don't. As I said initially, an advantage of using Exclusive is you keep DNS resolution of a domain, and subsequent access to the domain, bound to the same network interface. But it also undermines you're ability to bind at least *some* of your VPN clients to DNSMasq for the purposes of bypassing the VPN in favor of the WAN. I'm not sure I have a good solution.

Is it possible to use Exclusive w/ NordVPN, but bind those devices that need access to Netflix to ExpressVPN, and have ExpressVPN set to Disabled? Or is it the case that the devices that need access to Netflix and YT are one and the same?

 

[eibgrad]

I was thinking of another modification that might solve the problem.

It might be possible to intercept Do53 requests that contain these domain names (doing a packet search) and specifically redirect them back to the router and DNSMasq. That would allow the VPN to continue to be configured w/ Exclusive for all other purposes.

I know the URL filter is capable of blacklisting domains using this technique, so I don't see why the same couldn't be used for redirection.

 

[bonezy]

Well here's an example of where you might be running into a conflict because your are NOT using the DNS server(s) provided by the VPN. IOW, you're damned if you, and damned if you don't. As I said initially, an advantage of using Exclusive is you keep DNS resolution of a domain, and subsequent access to the domain, bound to the same network interface. But it also undermines you're ability to bind at least *some* of your VPN clients to DNSMasq for the purposes of bypassing the VPN in favor of the WAN. I'm not sure I have a good solution.

Is it possible to use Exclusive w/ NordVPN, but bind those devices that need access to Netflix to ExpressVPN, and have ExpressVPN set to Disabled? Or is it the case that the devices that need access to Netflix and YT are one and the same?

I won't bore you with the details of the things I tried after reading your post but the first thing I thought was that I hadn't set up NordVPN for Asus Merlin, exactly as suggested in their post here.

ExpressVPN set up for Asus Merlin does not require this in their guide but NordVPN does. It says that you should add their DNS addresses but I hadn't done it cause I didn't want to muck up the DoT settings I had in place. I tried it without them and it worked so I never bothered again. I just thought I should mention it, don't know if it makes any difference.

To cut a long story short, I tried following NordVPN's guide to the end and disabled my DoT settings, but for some reason (which I cannot understand), the router just wouldn't connect to my ISP's modem anymore, so I abandoned the effort completely.

Re your new post and URL filtering how would that work? I added the word youtube in the URL Filter list in the Firewall section but Youtube still loads up in my browser.

 

[eibgrad]

Re your new post and URL filtering how would that work? I added the word youtube in the URL Filter list in the Firewall section but Youtube still loads up in my browser.

I was only referring to the URL filter as an example of how it's possible to examine the contents of a udp or tcp packet, then take actions based on what you find. In the case of the URL filter, it examines the contents of Do53 packets for a match on the domain name and creates firewall rules to DROP them (it's not obvious by just looking at the GUI that it's doing this, but it is).

So it seems plausible to me that you could use the same technique (using a script, NOT the URL filter) to create firewall rules that detect the use of specific domain names in Do53 packets, and redirect them to the router's DNS server! In that way, you could continue to use Exclusive w/ the VPNs and (presumably) avoid the negative side-effects of having to specify Disabled. IOW, for those bound to the VPN, it becomes possible to have *some* name resolution occur w/ DNSMasq, and the rest w/ the VPN's DNS server.

That's the theory anyway. I've yet to implement the changes. I was just anticipating that you would probably run into other problems by changing Exclusive to Disabled, even if those changes helped w/ Netflix.

 

[bonezy]

OK. So I've reverted back to my normal settings for everything with the only exception being disabled in the NordVPN client and rebooted.
For some reason (which again I don't understand why) F1 YT channel works. I checked my IP and it's in the Netherlands so the VPN is running and the DNSleak test shows some IP's in the UK but it still works, so I'm thinking of giving the script a whirl. I ssh to my terminal through an app called Termius on my Mac, so I'll run the

curl -kLs pastebin.com/raw/9jHRA6DG | tr -d '\r' | sh

A couple of quick questions.

Do I have to do something else beforehand?
If things don't go well, how do I revert?
Does this script route Netflix through the wan for all IP's?
Can I manually set which IP's I want to set?

Many thanks

EDIT: Just reread your whole post and noticed you mentioned not using QOS with this. I run cake on this router for my gaming rig, will it be a problem?

 

[eibgrad]

Do I have to do something else beforehand?

No.

If things don't go well, how do I revert?

Just delete the files the script created and reboot.

rm -f /jffs/configs/dnsmasq.conf.add
rm -f /jffs/scripts/firewall-start

Does this script route Netflix through the wan for all IP's?

Yes. It's completely unconditional. It assumes that if *anything* wants to access those domains, it *must* be routed through the WAN.

Can I manually set which IP's I want to set?

If you're simply restating the prior question, then No. As I said, the rerouting of those domains is unconditional. It applies to *all* clients, regardless if they are bound to the WAN or VPN.

EDIT: Just reread your whole post and noticed you mentioned not using QOS with this. I run cake on this router for my gaming rig, will it be a problem?

I have no way of knowing. As I said, anything that also uses marks could conflict. You'll just have to try it and find out.

BTW, I created a second version of the script that includes an openvpn-event script. What makes it different is that it searches any Do53 queries from any clients for a match on the ipset domain names. If found, it prevents that query from being resolved over the VPN due to the use of Exclusive. IOW, w/ this new script, it's possible to continue using Exclusive for those things you still want to resolve over the VPN, because it treats the ipset domain names as exceptions and forces them through DNSMasq.

I just had a strong feeling that you would have other issues if forced to use Disable on the VPN just to make this all work. But if you've finally worked around any such issues, perhaps this new script isn't necessary. That's why I did NOT overlay the current script, but created a complete new one. If you prefer it, let me know and we can rid of the old script.

merlin-ovpn-lan2wan-71993-v2.sh - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

 

[eibgrad]

FYI. I decided to just update the original script w/ the most reasons changes. Now it's possible to restrict the remote domains bound to the WAN to specific sources. And as I stated before, you can use Exclusive as well for the VPN, since the script now detects its usage, and will prempt the use of the OpenVPN provider's DNS server for those domains bound to the WAN through this script.

Again, I don't know if you needed either of these capabilities, but since I expect others to consider using this script as well, I thought it might be helpful for them.

P.S. I can't emphasize this enough. This technique of using ipset is *only* as reliable as your ability to make sure DNSMasq is being used for name resolution by the affected clients. And that's not always easy to do. For example, if a client has already performed a domain name lookup prior to the these various changes being applied, that client will NOT use the WAN for those domains as long as that name resolution remains cached locally. That's the achilles heel of using ipset and DNSMasq, and why it may appear at times NOT to be working. You may have to restart devices/apps in order to clear their DNS cache. And make sure they're NOT using something other than Do53. IOW, it will always be somewhat of a fragile solution, esp. given all the various DNS alternatives available today. Caveat emptor.

 

[eibgrad]

Frankly, I'm not the sure the OP is still interested, but since I've put this much effort into the script, and others are likely to try it, in the name of full disclosure, I have to warn you that I've found a flaw. A flaw that's not easily correctable (although I'm working on it).

What I'm finding is that the router will restart the firewall for no obvious reason. It just happened this morning. I was running the script overnight to make sure it was reliable, and discovered all my firewall rules that got added to the DNSVPNx chains are missing! Everything else, all my data structures and changes, are still there.

Oct 17 08:05:50 lab-merlin1-355B6FE-C rc_service: amas_lib 489:notify_rc restart_firewall

I can't tell what's triggering it. Based on the syslog, it just seems to come out of nowhere. I do know it's possible for certain end-user actions to trigger it, such as enabling/disabling a guest network. But the one from early this morning remains a mystery.

Here's the issue. I can't add the DNSVPNx specific rules to the firewall-start script since the OpenVPN client doesn't use the firewall service. I have to respond to the establishment of the OpenVPN client using the openvpn-event script in order to add them. But if the firewall is reset for any reason, those chains are cleared, and the router is (apparently) notified through a back-channel that the firewall has been reset, so it can reconfigure them. But *I* get no such notification! I only know something's changed if the VPN is reinitialized for some reason and triggers the openvpn-event script.

Ugg!

Frankly, it doesn't surprise me. That's why I always conduct long term testing. What initially appears to work, may fail over time for one or more reasons. And that's a common theme w/ third-party scripting. You're never fully integrated into the system the way the actual firmware is. And in this particular case, because the OpenVPN client is NOT bound to the firewall service in order to create and maintain its own firewall rules, it makes things difficult for me should changes occur elsewhere in the system that trigger the reinitialization of the firewall.

Anyway, I don't know if any of that makes sense. But at the moment, it's not quite working correctly. I have to find a way (assuming there is one) to solve this problem if I expect to reliably allow the use of Exclusive.

 

[eibgrad]

FYI. I updated the script to v2.2.0. I decided to call the openvpn-event script from the firewall script as well, just in case the firewall gets reinitialized while the OpenVPN clients are active. It checks if the DNSVPNx chains in the nat table are still populated w/ the Do53 string searches (most likely NOT) and adds them back as necessary. A quick check of enabling/disabling any of the guest networks (which I know triggers the firewall reinitialization) seems to confirm it's working.

I also noticed that if I allowed the lan2wan hash table to be cleared in the firewall script, a running Netflix video would immediately detect the presence of the VPN. So I changed the script to never flush the hash table once established and populated. It will take a reboot of the router to have that happen. Seems to have made a big difference in the reliability of the stream.

Obviously I would have preferred to avoid these complication (makes things a bit more messy), but I don't know of a better solution. I'll run it overnight over the next few days to make sure it continues to work.

(Yes, I know I'm probably talking to myself, but that's ok )

P.S. I'm even considering the possibility of perhaps making the contents of the hash table persistent across a reboot, or at least as an option, just to increase the reliability of the stream even more.

 

[john9527]

(Yes, I know I'm probably talking to myself, but that's ok )

No....at least one other....me I'm always learning and appreciate your insights...

 

[eibgrad]

FYI. v2.4.0 is now available.

I added several options (switches).

DEBUG: You can more easily enable/disable debug mode across all the scripts w/ this switch (it's enabled by default).

LOG_QUERIES: When enabled, it will output details about DNS queries to the syslog, making it easier to determine what domains are actually being used by specific clients (it's disabled by default).

SAVE_RESOLVED: This will save the contents of DNS resolution across a reboot (it's disabled by default).

Note, the script only saves the resolved domain names if something has changed. And it's only saved during the shutdown process triggered by a reboot. I wanted to minimize the wear on JFFS (not that it would matter all that much, but still). With enough time, you'll probably reach a point where saves are quite rare, as the chances of finding any new resolutions begins to diminish. If you want to start fresh, you'll need to manually delete the following file: /jffs/services-stop.lan2wan.ipset.

I've been running it over the past couple of nights, and so far so good. Any lost Do53 string searches in the DNSVPNx chains due to firewall restarts are restored as needed. And w/ the use of a persistent store of resolved domain names (esp. across reboots), streaming is quite reliable.

I've also changed the way I use marks to *hopefully* make the script more compatible w/ QoS (or anything else using marks). As I've stated previously, trying to integrate your own marks w/ existing QoS is tricky since the developers never anticipated anyone else wanting/needing to use marks for their own purposes. And as such, the various QoS profiles often set marks by clobbering the whole field, rather than masking for only the bits needed. Therefore I can't make their marks and my marks available at the same time. Either QoS takes precedence, or my script does, depending how I configure the PREROUTING chain of the mangle table. Until now, I've given QoS (and anything else that uses marks) higher priority. But I changed that w/ this release so the script is given highest priority. What that means is the script is (hopefully) able to co-exist w/ the built-in QoS profiles (I can't speak to third-party options like Cake), but those packets will probably NOT participate in QoS. IOW, it's a compromise. Better to force packets over the WAN w/ no QoS, than have them routed over the VPN w/ QoS. At least that's the theory. But the fact the system is "greedy" when it comes to marking packets makes it darn near impossible to ensure 100% compatibility. I did a cursory once-over of the various built-in profiles to make sure things looked copacetic. But only real world testing will prove one way or another. I wanted to at least make an attempt. Worst case, you simply won't be able to use the script w/ QoS at the same time.

Beware, the script has reached the point where its size is likely to exceed the ssh client's input buffer, causing it to report errors if you try to copy/paste it into the ssh terminal window. At that point, you have no other option than to download the file w/ curl, either for immediate execution (if you're willing to accept the defaults) …

curl -kLs pastebin.com/raw/9jHRA6DG | tr -d '\r' | sh

… or to a file which you can edit ...

tmpfile=/tmp/temp.$$.sh
curl -kLs pastebin.com/raw/9jHRA6DG | tr -d '\r' > $tmpfile
chmod +x $tmpfile
nano $tmpfile

… then execute ...

$tmpfile

Hopefully this is the last of the major changes. I may add a little more documentation to the script (pretty sparse at the moment), but that's about it.