Disney+ and Netflix don't respect VPN on WLAN

[iTyPsIDg]

I have all my WLAN traffic routed through NordVPN to the US (I'm in Mexico) on my router. I also have three Guest WiFi networks using YazFi. Guest 1 2/5GHz use US, Guest 2 2/5GHz use Local (Mexico), Guest 3 2/5GHz use UK.

Streaming services can tell I'm in Mexico on WLAN. If I use Guest 1/3, Netflix accurately works as if I'm in the US/UK. Disney+ also seems to work on Guest 1/3. Guest 2 goes to Mexico, so it shouldn't work anyway and it doesn't.

DNS Leak Test and IP Leak both say I'm in the US on WLAN. It seems like something is leaking out on the WLAN that makes some streaming services think I'm not in the US.

There's a work website I use that blocks Mexico and it isn't blocking me on the WLAN, so I'm not sure what extra that these services are doing that would cause an issue.

I'm guessing it's something in the routing, but I'm new to working with Merlin and VPNs on the router.

Spoiler: Here are my routing rules for the US VPN

.

I haven't been successful setting the Telmex router up in bridge mode, so my router does have a private IP from the Telmex router.

What should I try next?

 

[Huib]

If you're using a smart device to watch Disney+ try turning of location services for Disney+ (or altogether) when using Disney+

 

[New2This]

I did that, just had to input my username and password again..

 

[CaptainSTX]

I have all my WLAN traffic routed through NordVPN to the US (I'm in Mexico) on my router. Disney+ won't run because it can tell I'm not in the US; however, if I also turn on the NordVPN app on my FireStick or phone, it launches finally. At that point, I'm double-VPNed. I hope this is something simple to resolve. Even Netflix works fine for me, and they are usually the worst.

DNS Leak Test and IP Leak both say I'm in the US.

What should I try next?

There are other ways to detect your location besides IP.

If you have WiFi turned on, on your router the streaming service can by looking at what SSIDs you are receiving determine fairly accurately your location. As part of Googles mapping and street view data collection Google collected millions of SSIDs and associated them with an actual physical location

Another trap is what time zone you are in? You can avoid this trap by being sure the time on your system or devices matches the time at your VPN end point.

Also contact NORD and ask them if they have any servers that Disney+ doesn't have on their naughty list.

 

[iTyPsIDg]

I'd like to apologize to everyone that has tried to help so far. I should have looked for a better show to test my Netflix theory (e.g., Schitt's Creek is not available for Mexico Netflix, but it works in the UK and US).

I'll edit my OP with my latest findings. Now I think I have something wrong in a route or maybe somewhere else.

 

[eibgrad]

Just as a side note (I don't think this directly affects your current problems), those last two PBR (policy based routing) rules are unnecessary.

If the Telmax's network (192.168.1.x) lies directly upstream of the router (in which case the WAN would have an IP assigned in that same network), then that rule is superfluous. The routing table will already have a route to that network over the WAN, so it will automatically be routed there.

The Router rule is also superfluous. Whenever PBR is enabled, it automatically takes the router itself OFF the VPN and back to the WAN. But even if that wasn't the case, the router's LAN ip is irrelevant. When the router accesses the internet, it isn't using the LAN network interface (i.e., 192.168.50.1) as a source IP for that access. It's using the IP address assigned to either the WAN or VPN network interfaces, which of course can vary since both are typically assigned dynamically. In short, for all practical purposes, PBR has no relevance to the router itself (except in some very specific and limited instances), whether referenced explicitly (192.168.50.1) or implicitly (192.168.50.0/24).

(I'm not even sure what DummyVPN is doing)

Having these two rules is probably not going to hurt anything, but just beware they are not doing anything either. I think it's worth understanding what's actually happening so you can apply your rules effectively.

As far as your immediate problem, I don't find online leaktest tools all that reliable. At least as far as the router is concerned. Remember, your clients are using DNSMasq (a local DNS proxy), which effectively *masks* the actual public DNS servers from the client! IOW, for any given client, the actual DNS server accessed is once removed from that client. Online leaktest tools are far more accurate when the client is directly configured w/ public DNS servers. In my own case, using ExpressVPN, these leaktest tools almost never get it right. Most seem to be *guessing*, perhaps based on my public IP (perhaps they have a database of who owns which public IPs and the DNS servers they offer to those customers in that region, at least it seems that way, hard to be sure).

The *only* way I've found to be 100% sure what DNS servers are being accessed in any given situation is to monitor connection tracking on the router. Unfortunately, that's beyond what most users want to deal with. It's tedious and takes some time to learn.

cat /proc/net/nf_conntrack

Of course, the reason this matters is because sometimes these content providers are able to detect that their DNS queries are being routed over a VPN, even if the stream isn't, and so they refuse to run (e.g., Netflix). And so knowing w/ certainty whether your DNS is bound to the WAN or VPN becomes critical.

Unfortunately, once these content providers decided to enforce their region rules a few years ago, things got a whole lot more difficult and complex when it comes to circumvention. That's why it can be really tough to determine where the problem lies.

 

[iTyPsIDg]

If the Telmax's network (192.168.1.x) lies directly upstream of the router (in which case the WAN would have an IP assigned in that same network), then that rule is superfluous. The routing table will already have a route to that network over the WAN, so it will automatically be routed there.

I found that I had to add the Telmex route or I couldn't access the Telmex router's web GUI to make modifications. Without it, I had to keep switching networks to access it. I wasn't sure about the Router option. I found it online somewhere so I thought maybe it might help. Spoiler: It didn't lol. I'll remove it.

(I'm not even sure what DummyVPN is doing)

I saw DummyVPN auto-created by YazFi on both of the other VPN connections. I think I'll try deleting all the routes on VPN 1 and then let YazFi recreate the setup to see if it is necessary.

It's just super strange that Guest 1 and WLAN both use the same VPN 1 client yet only WLAN doesn't work as I would expect.

I also noticed that I forgot to mention VPN Manager in my siggy to help understand what I have configured on the router. I'll go fix that.

I had my CCNA about 10 years ago but never really used it. I don't mind learning this stuff, so thanks for the tip with connection tracking. I'll take a look at it as well.

 

[iTyPsIDg]

I have some more interesting results now.

If I set DNS filtering as follows:

Spoiler: LAN -> DNSFilter

If I use NordVPN's DNS servers for the MAC addresses for my FireSticks, then Disney+ and Netflix think I'm in the US. If I leave it as Router (delete those clients), then it doesn't work. This is a good workaround, but I'm interested in further troubleshooting this if anyone is willing to give advice.

Here are screenshots of all the packages I have installed, in case that helps.

Spoiler: amtm

Spoiler: Entware

 

[Jack Yaz]

DummyVPN was necessary due to an issue where routing tables weren't properly set up if you enabled PBR without adding any rules. I /think/ that's actually been resolved in 386, I'll go digging in the commits. (or @dave14305 will beat me to it)

EDIT: https://github.com/RMerl/asuswrt-merlin.ng/commit/ad9773d711ab7439e63d3544567fb2f822b93c2c
I'll remove DummyVPN workaround for 386.x
@Xentrk this may affect x3mrouting too

 

[iTyPsIDg]

I managed to fix the issue by using these settings in WAN DNS, along with DNS Filter set to router:

Spoiler: WAN DNS

 

[Xentrk]

DummyVPN also used for x3mRouting modified OpenVPN GUI screen as follows..

For the selective routing of IPSETs, creating a “dummy” VPN Client entry is required if no routing rules exist for LAN clients and you need to exploit the Accept DNS Configuration=Exclusive feature. The appropriate DNSVPN iptables chain rules will only get created if the routing table isn't empty in the OpenVPN Client Screen. Use a bogon IP address for this purpose. Use the word "DummyVPN" as the first eight characters followed by the number of the VPN Client. This will prevent a Routing Policy Database Rule (RPDB) reservation from getting created for the DummyVPN entry.

From reports on the forum, I have concluded that Nord and ExpressVPN require use of their DNS to circumvent VPN blocks. DNSFilter can help here. Accept DNS = Exclusive can work as long as you don’t require the use of dnsmasq for Diversion or the ipset feature built into dnsmasq.

 

[iTyPsIDg]

The Router rule is also superfluous. Whenever PBR is enabled, it automatically takes the router itself OFF the VPN and back to the WAN. But even if that wasn't the case, the router's LAN ip is irrelevant. When the router accesses the internet, it isn't using the LAN network interface (i.e., 192.168.50.1) as a source IP for that access. It's using the IP address assigned to either the WAN or VPN network interfaces, which of course can vary since both are typically assigned dynamically. In short, for all practical purposes, PBR has no relevance to the router itself (except in some very specific and limited instances), whether referenced explicitly (192.168.50.1) or implicitly (192.168.50.0/24).

I came across that link again regarding the router rule. It's from @Xentrk .

 

[eibgrad]

I came across that link again regarding the router rule. It's from @Xentrk .

I presume you're referring to the following.

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN
Router     192.168.1.1       0.0.0.0    WAN

As I said, that Router rule is superfluous. The reason the router itself (i.e., its own processes) gets routed over the WAN is NOT due to that rule, but rather because a side-effect of using PBR (policy based routing) takes the router itself OFF the VPN! A such, you can remove that Router rule and everything will work exactly the same.

In fact, one of my on-going complaints about using PBR is precisely this, that it takes the router itself OFF the VPN, which can have unintended consequences, like having some process on the router you expect to be using the VPN, instead using the WAN (e.g., transmission). We see this same problem on FT (FreshTomato) from time to time.

To make matters even worse, even if it did work, it doesn't work as intended. It will only have an effect to the extent that processes on the router that are headed to the internet are actually bound to the LAN network interface (192.168.1.1). But in virtually all cases, such processes are either bound to all network interfaces (0.0.0.0), or specifically *exclude* the LAN network interface (e.g., 192.168.1.1). And because of that, the router will *always* chose the WAN network interface as its source IP for outbound packets, NOT the LAN ip. To actually be effective, the Router rule would have to use the public IP of the WAN, NOT the LAN ip.

To better understand my point, let's look at another example where we want to force transmission (running on the router) to use the VPN. But as I said before, w/ PBR active, it won't happen. It will use the WAN.

We can use the Router rule as described in that link to solve this problem, but w/ a slight modification.

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN
Router     192.168.1.1       0.0.0.0    VPN

Notice this time I changed the Router rule so as to bind the LAN network interface (192.168.1.1) to the VPN, NOT the WAN. Again, we need to do this because PBR being active will remove the router from the VPN. But it is NOT sufficient. We also have to change the transmission config file from...

"bind-address-ipv4": "0.0.0.0"

to

"bind-address-ipv4": "192.168.1.1"

NOW transmission will finally be routed over the VPN because we have forced that process to *only* bind to the LAN network interface, whereas without that change, it would use the WAN network interface (specifically its public IP) as the source IP for the outbound packets, NOT 192.168.1.1.

Fortunately, in this particular case, the effect of that Router rule in the link, is benign. But the lack of understanding about what's really happening w/ the routing tables wrt PBR can sometimes leads to rules that are NOT so benign, and unexpected results.

Yeah, I know, confusing, but read it over a few times and perhaps it will make more sense. This stuff just gets complicated.

 

[eibgrad]

BTW, just to show how easy it is to make a mistake w/ this stuff, even my slight modification to those rules in the link could be further modified.

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN
Router     192.168.1.1       0.0.0.0    VPN

to

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN

Because 192.168.1.0/24 *implicitly* includes 192.168.1.1, the Router rule is *still* superfluous! LOL

Of course, in the real world, you wouldn't likely be using 192.168.1.0/24, but something else, like 192.168.1.100, and so you would actually need the Router rule. But I find it funny how easy it is to miss stuff like this, even for me.

 

[iTyPsIDg]

BTW, just to show how easy it is to make a mistake w/ this stuff, even my slight modification to those rules in the link could be further modified.

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN
Router     192.168.1.1       0.0.0.0    VPN

to

LAN_IPs    192.168.1.0/24    0.0.0.0    VPN

Because 192.168.1.0/24 *implicitly* includes 192.168.1.1, the Router rule is *still* superfluous! LOL

Of course, in the real world, you wouldn't likely be using 192.168.1.0/24, but something else, like 192.168.1.100, and so you would actually need the Router rule. But I find it funny how easy it is to miss stuff like this, even for me.

Interesting. So, I wonder if I could put my WAN IP in the source and then point it to the VPN, would that also force my router traffic through the VPN? My WAN IP doesn't change since I have a weird configuration in which I'm forced to use a private IP due to Telmex.

Like so:

LAN_IPs    192.168.50.0/24    0.0.0.0    VPN
Router     192.168.1.80       0.0.0.0    VPN

 

[eibgrad]

Interesting. So, I wonder if I could put my WAN IP in the source and then point it to the VPN, would that also force my router traffic through the VPN? My WAN IP doesn't change since I have a weird configuration in which I'm forced to use a private IP due to Telmex.

Like so:

LAN_IPs    192.168.50.0/24    0.0.0.0    VPN
Router     192.168.1.80       0.0.0.0    VPN

The reason the Router rule in that link is NOT using the WAN ip is precisely because the author knows it's unlikely you'll know the public IP. Most ppl are stuck w/ a dynamic public IP. So he resorts to the LAN ip since at least that's known and fixed. But as I said, it won't work as intended.

 

[iTyPsIDg]

The reason the Router rule in that link is NOT using the WAN ip is precisely because the author knows it's unlikely you'll know the public IP. Most ppl are stuck w/ a dynamic public IP. So he resorts to the LAN ip since at least that's known and fixed. But as I said, it won't work as intended.

If by it, you mean using the "public IP" you are correct. I tried using the 192.168.1.80 IP to VPN and it killed my connection to the VPN client.

I assume it killed the connection because the router can't connect to Nord first so it kills the Internet because I'm blocking all traffic if the VPN goes down. This makes sense, if I don't have a VPN connection then I can establish a VPN connection anymore. I wonder if I could PBR 192.168.1.80 traffic going to 9.9.9.9 and 149.112.112.112 using VPN. That way the VPN can establish, then it routes my DNS traffic always over the VPN to use Quad9.

Oddly enough, I had this working before 386.1_2 by just using the setup per post 10. However, I also tried unbound and saw that it wouldn't work without x3m which I wasn't ready to install because my roommates wanted internet back and my RAM is only about 43MB free (does the RAM free really matter if you have a 2GB swap?). I uninstalled unbound and set up per post 10 again, but now it blocks Disney+ on my FireStick and not my phone. It's very bizarre behavior now.

EDIT: P.S. to add, thanks for all the insight. This is helping me learn the process immensely.

 

[L&LD]

Free RAM doesn't matter. The router will use and manage it as needed.

 

[Xentrk]

I believe NordVPN requires that you use their DNS over the VPN connection to circumvent the Netflix and Disney Plus blocks. In that case, Accept DNS Configuration=Exclusive is required.

 

[eibgrad]

@iTyPsIDg

If by it, you mean using the "public IP" you are correct. I tried using the 192.168.1.80 IP to VPN and it killed my connection to the VPN client.

If you force all WAN traffic through the VPN w/ the Router rule set to the WAN ip, that also includes the remote connection to the VPN server, which *must* use the WAN, so it makes no sense.

If, as @L&LD suggests, you need to force NordVPN's DNS servers over the VPN, then that shouldn't be a problem provided they are scoped within the same *private* IP network as the tunnel. That's the *only* viable route to those DNS servers, despite however Routing Policy is configured.

OTOH, if the NordVPN DNS servers are using *public* IPs, and the router is bound to the WAN due to PBR, you can create policy rules that bind those IPs to the VPN. You just have to place those IPs in the destination IP of the rule, NOT the source IP.