4

Disclaimer:

This is not a "I need VPN to surf Netflix". Surfing without VPN at this site allows Netflix.

The question is instead the other way around: "There is a PC that needs to Internet through VPN only, but Netflix detects it is behind VPN. How?"

First things to take into account:

  1. Netflix allows IPs from this VPN provider.
  2. We are in Italy.
  3. We use Italian servers from this paid VPN provider.
  4. We surf Netflix Italia.

VPN-only site diagram

If they connect to Netflix through Machine C, they get the message (translated from italian): "Something went wrong. Streaming error. Looks like you are using an unblocker or proxy, disable those services and retry. Error code: M7111-5059."

netflix error m7111-5059

Please note that this is not VPN server related. If C connects to the same VPN server used by A, but locally through the provider's VPN app, Netflix will not detect it as "behind an unblocker".

I would like to know what does Netflix detects in this setup that is instead undetected if the VPN app is ran right on machine C?

Can this type of detection be used by someone else (quite sure) with evil intentions? What am I actually revealing with my setup that stays undetected when the VPN app is run? How to troubleshoot this?

My customer isn't violating any Netflix's term of service, they just need to surf the web through VPN only, and they would like to use Netflix at lunch break.

I'm not concerned about their inability to watch TV shows at lunch: I'm mainly concerned that my setup could have an hole and others can actually track the real network's details when users do surf through Machine A's VPN.

Following suggestions in the first Answer from Mr. Yevhen Stasiv, I've run WITCH VPN Detector test and it doesn't show relevant differences between Machine A and Machine C's VPN. It only shows two hops less, 7 vs 9. (probably, Machine A and B indeed!!).

WITCH vpn through Machine A's VPN

WITCH vpn through Machine C's local VPN app

I also tried other MTU related tests, like the one on letmecheck.it and they all return 1472 as biggest unfragmented packet for both Machine A and C VPNs.

letmecheck.it mtu test

Configuration details follows:

At this site there are some PCs (like Machine C in the diagram) connecting through VPN only.

Machine A is an Ubuntu 16.04 box set up as gateway with firewall and VPN client.

Machine B is an IPFire firewall that doesn't do masquerading and has outbound filtering rules only.

A is default gateway for B. B is default gateway for the LAN with problematic PC (Machine C).

The VPN client of A is openvpn and it is connected to a popular paid VPN service.

Host: public/private ip

  • Provider's router: xxx/192.168.100.1

  • Machine A: 192.168.100.2/192.168.66.2

  • Machine B: 192.168.66.1/192.168.77.1

  • Machine C: 192.168.77.133

Machine A's setup:

Iproute2 config

root@scrrtr:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
100     Tprovider
150     Tvpn
0       unspec

root@scrrtr:~# ip rule show
0:      from all lookup local
32757:  from 192.168.77.133 lookup Tvpn
32762:  from all to 1.0.0.1 lookup Tvpn
32763:  from all to 1.1.1.1 lookup Tvpn
32764:  from 10.8.1.16 lookup Tvpn
32765:  from 192.168.100.2 lookup Tprovider
32766:  from all lookup main
32767:  from all lookup default

root@scrrtr:~# ip route show
0.0.0.0/2 via 192.168.100.1 dev ens160
0.0.0.0/1 via 10.8.1.1 dev tun0
default via 192.168.100.1 dev ens160
10.8.1.0/24 dev tun0  proto kernel  scope link  src 10.8.1.16
64.0.0.0/2 via 192.168.1.1 dev ens160
128.0.0.0/2 via 192.168.1.1 dev ens160
128.0.0.0/1 via 10.8.1.1 dev tun0
192.0.0.0/2 via 192.168.1.1 dev ens160
192.168.100.0/24 dev ens160  proto kernel  scope link  src 192.168.100.2
192.168.77.0/24 via 192.168.66.1 dev ens192
192.168.66.0/30 dev ens192  proto kernel  scope link  src 192.168.66.2

Iptables config

root@scrrtr:~# cat /etc/firewall/iptables.rules
[...]
-A POSTROUTING -o ens160 -j MASQUERADE
-A POSTROUTING -o tun+ -j MASQUERADE
[...]
-A FORWARD -s 192.168.77.133/32 -i ens192 -o ens160 -j DROP
-A FORWARD -i ens192 -o ens160 -j ACCEPT
-A FORWARD -i ens160 -o ens192 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ens192 -o tun+ -j ACCEPT
-A FORWARD -i tun+ -o ens192 -m state --state RELATED,ESTABLISHED -j ACCEPT
[...]

I'd like to know how to troubleshoot the difference between Machine A's and Machine C's VPNs. Netflix is just an excuse to find vulnerabilities in this network setup.

Improve this question
5
  • After such a spam answer I'm wondering if there's something wrong with my Q cause I don't know perfectly each rule of the site. :(
    – Marco
    Commented Jan 8, 2020 at 7:59
  • BTW after re-reading meta.serverfault.com/q/3608 I think the OP is fine and I'll keep it.
    – Marco
    Commented Jan 8, 2020 at 8:11
  • I suspect that Netflix is working off a list of known VPN service IP addresses. I hear that sometimes it takes them a while to notice a new one. Perhaps when you reconnect it gives you a new IP that Netflix doesn't know about yet?
    – Katherine Villyard
    Commented Jan 8, 2020 at 20:25
  • No @Katherine VPN servers from this ISP do have fixed addresses. They are allowed by Netflix, as running the VPN app right on the PC will let it surf via the same public ip as when connected through the Ubuntu gateway.
    – Marco
    Commented Jan 9, 2020 at 7:37
  • Netflix, and others, each use proprietary solutions that do multiple checks for this, and only someone from Netflix could actually answer what Netflix in particular does. Any other answers you get are pure speculation, and they are probably wrong.
    – Ron Maupin
    Commented Jan 20, 2020 at 23:45

1 Answer 1

Reset to default
1

Netflix can be doing some traffic analysis, maybe something like 'witch vpn detector' (https://github.com/ValdikSS/p0f-mtu-script)

Netflix filters address blocks associated with hosting providers, if you are able to get a residential IP, and VPN through it, you can access Netflix.

TCP/IP Stack variance

Improve this answer
8
  • 1
    This doesn't address the OP question: "why the same PC from the same network is detected behind unblocker if using VPN through the Ubuntu gateway and is not detected behind unblocker if the SAME VPN service is executed with it's provider's app locally on the PC?"
    – Marco
    Commented Jan 8, 2020 at 10:46
  • Why not? I believe that the way that his Ubuntu gateway is configured allows detectors such as the one I linked to see that he is using a VPN. Compare the MTU with your gateway vs VPN providers software.
    – Yevhen Stasiv
    Commented Jan 8, 2020 at 18:06
  • Thanks for your contribution. There are some things I will clarify with an edit before I will consider accepting an answer for this question.
    – Marco
    Commented Jan 10, 2020 at 18:30
  • Sure, go ahead.
    – Yevhen Stasiv
    Commented Jan 18, 2020 at 19:19
  • 1
    If you try a laptop/different machine from Machine C's position does it exhibit the same behavior? (Their server may be trying to connect back to the client and that attempt may be being blocked by the double NAT on your network). (Using a VPN directly from that machine would allow it to pass through the tunnel avoiding the 2 NAT)
    – Yevhen Stasiv
    Commented Jan 21, 2020 at 0:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .