My Netflix rant and workarounds for the recent blocking of IPv6 tunnels

7
a5d5a2e0a42db8099ee714d4ee0e8987

Recently Netflix decided to block IPv6 tunnels, as part of the on-going geo-unblocking agenda. No doubt this is due to pressure from the various media corporations/license holders that have been behind the blocking of proxy and VPN services as of late. This time however, its a little bit of a different situation. IPv6 tunnels are primarily not designed to be services to circumvent geo-blocking and many users of such services have totally innocent intentions when using an IPv6 tunnel, mainly because their ISP doesn’t provide IPv6 connectivity natively yet. I am one of those users in the UK, who has a Hurricane Electric IPv6 tunnel and was surprised to learn Netflix is straight blocking them now. Find out how I worked around the problem without giving up my IPv6, while also ranting at Netflix about the whole thing.

My personal opinion on the blocking of IPv6 tunnels

Feel free to keep scrolling past this…

Ironically, Netflix was one of the major corporations to deploy IPv6 in their network (I believe it was 2012) when IPv6 was still in its very early days (in terms of usage by major organisation). Now, we now face a situation where we have to essentially disable Netflix from attempting IPv6 connections due to IPv6 tunnels being blocked. Talk about stunting IPv6 usage/adoption! The main problem stems from the fact that my IPv6 connectivity is not coming from the same ASN (ISP) as my IPv4 connection and Netflix is now simply treating this as “you must be bypassing our geo-restrictions, blocked!”. Not true. The reason why I use an IPv6 tunnel is because major United Kingdom ISP’s have been painfully slow at IPv6 adoption, hopefully towards the end of 2016 this should no longer be the case, but I’ve been running a 6in4 tunnel for well over two years now. During this time I’ve been able to work with IPv6 and obtain good knowledge about the protocol as it becomes more widely adopted. Something I would not of been able to do without my Hurricane Electric tunnel.

To further compound the problem. Geo detection with IPv6 is so hit and miss, you can’t actually rely on it currently, it may get better in the future, but most of the time it can be rather inaccurate. This is where part of the argument comes in for Netflix to be more pro-active in how it is treating IPv6 tunnel users. As a general example, my IPv6 tunnel goes through one of the London endpoints at Hurricane Electric. Nothing unusual about that. I’m in the UK, I obviously want to get the best performance and lowest latency. If I intended to circumvent Netflix and it’s crap geo-detection system, I would have simply chosen a US endpoint. I didn’t. The next problem is because of the Hurricane Electric IPv6 ranges and how Netflix identifies them. They all identify as US to most geographical location detection services, because the prefixes are all from ARIN and therefore generally assumed, all the tunnels are US. A rather wrong and wild assumption in this case. The problem is even messier when the traffic ultimately does up going through the HE network via US servers and that’s why Netflix thinks you’re in the US and serves you the US library of content.

While I admit, up until June (2016), I would always get the US Netflix listings, it was rather a side effect of a network setup, rather than a direct intention of circumventing content restrictions. Its certainly something I didn’t aim to achieve. In fact it was sometimes a problem, because Netflix could sometimes detect something wasn’t right and some content simply wouldn’t play, there are other potential pit falls to this as well, mainly your “Watch list” isn’t maintained across multiple regions, it only works for the origin of your account when you set it up, similar point for ratings as well. I essentially trapped myself to getting the US Netflix at home because I had no way to disable my IPv6 easily without causing some serious breakage on my network.

Overall I’m disappointed with Netflix and straight blocking of all IPv6 tunnels. The fact that they are a completely legitimate service and have even less piracy/bypassing appeal than a proxy or VPN makes me wonder who’s really in control at Netflix HQ. Netflix could and should do a better job of handling this. Rather than the dreaded “M7111-1331-5059” error. Which should be probably just be renamed to “YOU-ARE-A-CRIMINAL”, seems that’s how IPv6 tunnel users are getting treated now.

</rant>

Fixing this bull****

With my rant over, I’ll now present some logical options/solutions you can do to keep both your IPv6 tunnel and Netflix happy in your network:

  • Prioritise IPv4 connections over IPv6
  • Null route the Netflix IPv6 ranges
  • Force DNS requests for Netflix services to be IPv4 (A) only

Disabling the tunnel is obviously the easiest solution to start with, but its not as simple as it Netflix support might make it out to be. Particularly if you are like me and have your IPv6 tunnel configured at the higher network level across a LAN. Simply removing it entirely is going to cause problems, more so if you’re actually using your routed /48 and /64 for local servers running in the network. If you configured your IPv6 tunnel on a specific machine, then its easier to disable it, but again why should you?

Another solution would be prioritise IPv4 over IPv6. This would be reversing the default behaviour of IPv6 being used first. This can work but would require an override being made on every single device you want to have Netflix working on while having IPv6 connectivity from a tunnel active. If you only have a few devices, this might work for you. Its pretty much a no go for larger networks and is technically undoing the point of having IPv6 deployed in the first place, if you are constantly using IPv4 all the time where IPv6 is available.

A more technical approach is to null route the Netflix IPv6 ranges, so when an IPv6 connection is attempted it will be deemed as “non-functional” meaning Netflix falls back to IPv4 with the happy eyeballs specification in play, there would be very little delay for modern devices as well. This can be done a variety ways, but here’s a generic example on a Linux based router.

# Example Netflix IPv6 prefixes.
ip -6 route add blackhole 2620:108:700f::/48
ip -6 route add blackhole 2a01:578:3::/48
# Check routing table with
ip -6 route

You may have to add more prefixes to make this solution work.

While this method is pretty effective, there is a rather big caveat to this solution, Netflix uses Amazon Web Services as a CDN, therefore some of the “Netflix ranges” are actually part of the Amazon Web Services network and not Netflix directly. This means that in order to block Netflix you’ll also have to block legitimate AWS servers over v6, there is also the possibility that the ranges might change from time to time as well, requiring maintenance of the null route list. Not something I fancy doing.

The final option that I personally implemented, is to essentially force any Netflix DNS requests to always return A (IPv4) records and not AAAA (IPv6) records, this will then automatically make Netflix use IPv4 despite the IPv6 tunnel being active. In order to do this however, it does require some knowledge of DNS and forwarders. Its at this point where the solution can be a bit technical and might not be suitable for everyone. Fortunately, a project on GitHub was recently created where someone has done the hard work and created a DNS proxy in Python specifically for Netflix related DNS request. You just need to run it on a machine somewhere and make sure any Netflix requests goes there instead. I’ll cover more technical examples below.

Filtering AAAA lookup responses on Netflix domains

You can find a streamlined and more technical write up of this information on this gist on GitHub.

To start, as a minimum you will need to have the ability forward any requests made to netflix.com to another DNS server under your control, there are also additional Netflix domains you may also want to forward, as these domains are involved with various streaming activities and may also go v6 in the future.

  • nflxvideo.net
  • netflix.net
  • nflximg.net
  • nflxext.com

In my own network setup, I have a couple of local Windows Domain Controllers running DNS for Active Directory and hand off external requests to my DD-WRT router running Dnsmasq.

Dnsmasq examples:

# Dnsmasq Netflix forward example to a specific client on a LAN
server=/netflix.com/192.168.1.10

192.168.1.10 is an example of a fictitious local server that’s going to be configured as a DNS server, its doesn’t have to be a local server within a LAN and in fact could be multiple servers. Another option is if you have a router running OpenWRT or DD-WRT, you can also run a BIND DNS server on the router itself and configure it to listen on a non-standard port for DNS, as Dnsmasq typically controls DNS tasks overall on OpenWRT and DD-WRT routers.

Next you need to be running another DNS server somewhere in a network. It can internal or external. You can use the DNS proxy script mentioned above or alternatively setup a BIND9 server. Both will do the same job in this case, however currently the DNS proxy script only targets Netflix related domains, this is obviously the point of the project, but it’s very possible that other streaming services may follow what Netflix have done and also start blocking IPv6 tunnels, personally if you’re comfortable enough to configure BIND9, go with running your own DNS server, that way you can conditionally forward any future domains to it without too much hassle, I’ll cover the more technical BIND9 setup in more detail below.

BIND9 Setup

If you want to setup your own DNS server and use it for domains other than netflix.com you can use BIND. The package required to be installed will usually be named bind or bind9 which can be installed via whatever package manager your system uses. For routers running OpenWRT and DD-WRT, you will need to use ipkg or opkg.

Amend your named.conf to something similar like the example below. Bearing in mind that this bind server is designed to be purely for removing AAAA records from DNS requests that are forwarded to it, so it’s going to be a pretty minimal configuration.

Depending on where you are running this bind server, you may want to run it on a non standard port for DNS requests, this is useful if you are running something like Dnsmasq on the same place you are setting up bind, Dnsmasq supports the ability to specify a specific DNS port for forwarding requests:

Dnsmasq non standard DNS port example:

server=/netflix.com/127.0.0.1#2053
// Bind DNS configuration for removing AAAA records

// If running this on a public DNS server, otherwise leave this part out.
acl "trusted" {
    x.x.x.x/32;
};

options {
    directory "/tmp";

    // Change to whatever forwarders you want. This config uses OpenDNS.
    forwarders {
        208.67.222.222;
        208.67.220.220;
    };
    forward only;

    dnssec-enable no;
    auth-nxdomain no;

    listen-on port 2053 { 127.0.0.1; }; // Bind to a non localhost address if required
    filter-aaaa-on-v4 yes;
    allow-query { any; }; // If running a on a public IP
    allow-recursion { trusted; }; // If running a on a public IP
    allow-query-cache { trusted; }; // If running a on a public IP

};

I’ve set “any” for the listening configuration, because I’m lazy and my firewall would prevent anyone on the outside being able to make requests to this server. If you want to run this a public facing IP address, you’ll need to be more careful. I’ve provided an example acl to avoid becoming an open DNS resolver to the world (if you don’t firewall or acl accordingly, you will be abused, mark my words!).

The magic here however is the “filter-aaaa-on-v4” option. What this will do is essentially remove any of the AAAA records returned in a DNS query. Obviously in a general scenario, this is not something you’d normally do but without this specific configuration however, you cannot stop a DNS request from returning AAAA records. Once this has been implemented, I started the named service and confirmed that the DNS workaround was working with dig. The first example is using Google’s public DNS service (more on this later), which won’t treat netflix.com any differently. The second example, being our implemented DNS workaround.

An AAAA DNS request made via Google Public DNS:

dig @8.8.8.8 netflix.com AAAA

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @8.8.8.8 netflix.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21293
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;netflix.com.                   IN      AAAA

;; ANSWER SECTION:
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:fc9
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:177c
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:fed
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:25bf
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:d62
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:1cd2
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:22b2
netflix.com.            59      IN      AAAA    2620:108:700f::36d6:1699

;; Query time: 36 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 25 12:51:43 GMT 2016
;; MSG SIZE  rcvd: 264

An AAAA DNS request made via the BIND DNS server we setup:

dig @127.0.0.1 netflix.com AAAA

; <<>> DiG 9.9.9-P3 <<>> @127.0.0.1 netflix.com AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36923
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;netflix.com.                   IN      AAAA

;; Query time: 130 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 25 12:51:43 GMT 2016
;; MSG SIZE  rcvd: 40

You’ll notice that on our new DNS server that’s been setup, despite requesting the IPv6 AAAA records, we don’t get any. This is what we want as it will allow you to keep a IPv6 tunnel active without getting any proxy/VPN warnings from Netflix when streaming content. Netflix will now be forced over IPv4 as long as the DNS request only returns A records. Success!

For redundancy, it would be ideal to run multiple DNS proxy instances or BIND9 DNS servers on a network rather than point the netflix.com forwarder to one single server. This is obviously optional, if you have a spare resources on something like AWS, you easily spin up a couple of EC2 machines for this job though a little overkill for one service. Running this DNS workaround on a router is also a good alternative as it will always be “on”.

Chromecast DNS

If you happen to use a Chromecast device and cast Netflix you’ll probably notice that the VPN/Proxy message still appears after implementing this fix when casting Netflix from Google Chrome or an iOS/Android device. This is because the Chromecast device has its DNS hardcoded to the Google Public DNS addresses of 8.8.8.8 and 8.8.4.4, so Netflix requests will once again want to go over IPv6. In order to prevent this, a specific behaviour can be leveraged whereby if you block access to the Google DNS servers themselves at the router level, Chromecast will use the DNS settings pushed via DHCP, which should now be already in place to fix Netflix. In this case, a simple iptables firewall rule can be applied to block Google’s public DNS service from working on the network:

iptables -I FORWARD --destination 8.8.8.8 -j REJECT
iptables -I FORWARD --destination 8.8.4.4 -j REJECT

You can confirm the block is in place, by pinging both IPv4 addresses of the DNS servers. Here the expected output is the router returning a response of unreachable, because of the reject rules in the firewall. I would recommend you use REJECT rather than DROP as it is more graceful.

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

Pinging 8.8.4.4 with 32 bytes of data:
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.
Reply from 192.168.1.1: Destination port unreachable.

It appears, despite the Chromecast not able to have the DNS settings changed directly, the developers of Chromecast probably considered the scenario where by the Google DNS servers cannot be reached, and therefore should still allow the DNS to overridden in certain circumstances, albeit “not easily”.

Reboot the Chromecast device to ensure the new DHCP info is applied and the DNS configuration distributed via DHCP should now be working. Another success!

I hope this article provides valuable info for anyone wanting to keep their IPv6 tunnel while maintaining a working Netflix experience! Its a shame I have to jump through hoops to get a single service working, but hopefully my ISP (Virgin Media) can hurry up and deploy IPv6 so I don’t have to workaround these issues!

Share This:

  • The problem isn’t Netflix … OK, it is, partly, but the whois for HE’s netblocks return their US address – for ALL their netblocks. So Netflix has to assume HE subnets are all in the United States. The easier solution would be for HE to accurately place the correct country for each country they announce subnets in. In theory it shouldn’t be hard if they have deaggregated their subnets against each separate POP they maintain, i.e. /64s for the London POPs all come from the same upstream subnet.

    • That’s because HE’s IPv6 address space is with ARIN. There is a thread on HE’s forums that explains why its setup that way, plus the tunnelbroker service is free, you can’t expect HE to bend their setup for a free service. A whitelisting solution would work, that would require Netflix to also be willing.

      https://forums.he.net/index.php?topic=3564.0

      Geolocation with IPv6 is so sketchy you can’t even trust it half the time anyway.

      I disagree that the problem isn’t Netflix. It absolutely is a Netflix problem and has been poorly handled. BUT, I will accept that potentially Netflix themselves have had no choice in the matter either and simply got forced to do it.

      • Gushi

        Update: this kind of firewall broke for me and I was forced to also blacklist 2406:da00:ff00::/48

    • Brian

      The actual problem here is big media desperately trying to keep hold of last century’s business models based around charging multiple times for the same thing in many geolocations.

      That business model needs to die and any business not willing to let it die needs to die with it.

    • Sander

      My HE /48 and /64 netblocks return to Italy instead of the Netherlands.

  • George

    Thanks for the direction toward a solution. Can’t say I’m upset with either Netflix or HE. It seems like just a difference in priorities. Netflix is a business trying to make money and keep their content providers lawyers happy. HE is a group of engineering folks interested in doing cool things for the Internet community. They both seem to be doing well in their own right.

    • Pandorica

      I would say I’m disappointed with Netflix in the was this was all handled, rather than upset. HE has no part in this at all, not their fight/problem. I choose to run IPv6 over a 6in4 transit. I’m mostly annoyed at my ISP in general however, who are lagging behind in terms of IPv6 deployment, though it’s probably likely by mid 2017, I’ll finally have native IPv6 and won’t have to stop IPv6 connections being made to Netflix any longer.

      HE are an ISP who offer a wide range of services, the free tunnelbroker service (IPv6 tunnel) is something that enthusiasts have used because IPv6 adoption has been slow in their country or ISP. I’m glad I’ve had a IPv6 tunnel active for some years as I’ve been able to learn about and understand the IPv6 protocol and even deploy it at the network level. I wouldn’t of had this chance if I’d waited on my ISP (still waiting!).

      The DNS workaround is a bit of pain, because its another layer of network complexity to deploy, given that sometimes people like myself who do such things as a day job, it can get tiresome when it comes to your own home network!