VPN POLICY RULES - streaming provider through the wan

[70mmy]

I'm here to understand if my approach is right or not:
i m trying to let all traffic go through the VPN except for a specific streaming service
called NowTv which would be the light version of sky tv here in italy.
I used ettercap and wireshark to sniff the traffic my tv does when i open nowtv app
to try to find all the ip's that this streaming provider uses.
I found some ip of akamai and some belonging to sky,
then I correctly inserted for each ip or ip class a rule that would allow them to go
through the wan.

But all this was useless because i still get the app error saying i can't use the service with a vpn
can someone help me?

can someone help me?

 

[eibgrad]

This is not always as easy to remedy as it may first appear.

Many of the bigger content providers use *hundreds* of domain name and IP addresses, perhaps changing over time, so picking off a few here and there may not be sufficient.

Also, many are now able to detect if their use of DNS is being routed over a VPN and refuse to run (e.g., Netflix). So you may have configure their DNS queries so they route through the WAN as well.

 

[70mmy]

i did a test here https://www.dnsleaktest.com/ and it's ok so i think that's not the problem.
In any case what could be the most effective way to reach my goal?
My vpn provider works with all major services except this one and
every time I want to watch it it's a bit annoying to switch the settings

 

[ex99125b]

i did a test here https://www.dnsleaktest.com/ and it's ok so i think that's not the problem.
In any case what could be the most effective way to reach my goal?
My vpn provider works with all major services except this one and
every time I want to watch it it's a bit annoying to switch the settings

could you try setting static ip's for all of your other devices and set a policy for each of them to run through the vpn? Leave your nowtv box (or am I mistaken and its not a separate device?) to go through WAN.

 

[DeepAnger]

Why don't you just use a policy routing rule to send your TV through WAN instead of VPN ?

 

[70mmy]

the situation is a little more complex,
in practice I use the TV with the related streaming apps (disney, netflix, prime etc) and on all these the vpn works
except this damned one (NowTv / SkyIT)

 

[DeepAnger]

Oh well, as

eibgrad​

mentioned it would be almost impossible to do.

 

[ColinTaylor]

I think this is what x3mRouting was designed for (but I might be wrong about that because I don't use it myself).

GitHub - Xentrk/x3mRouting: Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware

Selectively route LAN clients, website or streaming media traffic over the WAN or OpenVPN client interfaces on Asuswrt-Merlin firmware - Xentrk/x3mRouting

github.com

 

[eibgrad]

i did a test here https://www.dnsleaktest.com/ and it's ok so i think that's not the problem.

A few things to be aware of.

You don't need to use PBR (policy based routing), which I assume is what you are using, in order to route *destination* IPs over the WAN. You can simply define these as static routes using the OpenVPN route directive in the custom config field.

route 199.199.199.199 255.255.255.255 net_gateway

PBR has the undesireable side effect of removing the router itself (and its internal processes) from the VPN. Sometimes that matters to ppl (e.g., they're using transmission on the router, which most ppl would prefer be routed over the VPN, for obvious reasons), sometimes it doesn't.

As far as the DNS leaktest, the purpose is to confirm (hopefully) that your DNS queries are being routed over the VPN. But that can be a problem when using some content delivery systems because it can detect its DNS queries are being routed over the VPN. And so it rejects it. One sure way to know if this indeed the problem is to force DNS over the WAN (i.e., actually create a DNS leak), at least temporarily. So let's assume your DNS is 8.8.8.8 and 8.8.4.4.

route 8.8.8.8 255.255.255.255 net_gateway
route 8.8.4.4 255.255.255.255 net_gateway

You also need to set "Accept DNS configuration" in the OpenVPN client to "Disabled" so the VPN server can't change your DNS to one provided by the VPN provider and only available over the tunnel.

If at that point everything starts working as desired, it's a pretty safe bet the problem is in fact DNS. And in order to get around it, you have to make an exception and route that device's DNS queries over the WAN. And one way to do that is to assign that one device it own unique DNS server (e.g., 1.1.1.1) (which can either be done on the client itself or by defining a dhcp-option in DHCP) and bind that IP to the WAN (which like above, can be done using a route directive in the OpenVPN client custom config field).

route 1.1.1.1 255.255.255.255 net_gateway

Of course, this will affect *all* the apps on that device, but there's little you can do about it.

Beware, some devices/apps *may* have a hardcoded DNS server they insist on using, despite anything you configure either on the client or via DHCP. If that happens, you have to determine what that is and bind it to the WAN.

 

[70mmy]

@eibgrad

thanks for your long post, from the further tests I did I definitely understood that it is not a dns problem because for one evening I was able to insert all the ip that nowtv used and in fact it worked!
BUT, the next day again it didn't work I tried to insert the ip again but nothing...

 

[eibgrad]

@eibgrad

thanks for your long post, from the further tests I did I definitely understood that it is not a dns problem because for one evening I was able to insert all the ip that nowtv used and in fact it worked!
BUT, the next day again it didn't work I tried to insert the ip again but nothing...

Well that kind of inconsistency is going to be hard to diagnose. Anytime you're making no changes and you get varying behavior, it suggests something *outside* the router's control is at play, perhaps just different servers being accessed by the content provider, ones you haven't accounted for.

As I said initially, this isn't as easy a problem to remedy as it may first appear. Not unless you're willing to use PBR to place the entire device (based on its source IP) on the WAN. Chasing domain names and destination IPs is like herding cats.