Netflix detects Toronto tunnel server as being in the US.

[primordial]

My Netflix service stopped working. For years visitors commented "you have US Netflix?!" and I said "No, not that I know of."

Turns out that I did and didn't even know it! Now Netflix is blocking me, and after a long while I finally figured out that it was because of my IPv6 tunnel. The thing is though, I am in Canada, and I use the tunnel server in Toronto, also in Canada, but Netflix detects my connections as coming from the US!

They (not very helpfully) say they can't do anything about it, and I must get my service provider to "fix" it. Well of course this problem only affects traffic coming over the IPv6 tunnel. If I shut it down, then Netflix works fine over native IPv4. I obviously still want my IPv6 connectivity, and don't have any easy way that I know of to specifically block only Netflix-related traffic from resolving IPv6 addresses and using the tunnel.

So, Tunnelbroker gurus, can you "fix" the tunnel server in Toronto to actually show up as being in Canada?

[broquea]

Our /32 is registered as part of a US company, and that is the address space being used there. We do not have any IPv6 allocations allocated and designated as "Canada". Our /32 is used globally, as-is. If Netflix has some sort of whitelisting system in place, perhaps the ranges used there can be submitted, if such a whitelist exists, Netflix willing.

[kcochran]

Just as an additional addendum: there's no central repository for geolocation<>IP data.  Anyone telling you otherwise is trying to sell you something (possibly geolocation services).  The closest thing to such is the regional registry's data of who has been allocated which blocks of IPs.  At best that tells you where the business is located, but doesn't mean anything in regards to any end-user's location using that IP.  We publish reasonably anonymized location data (city, region, country) in rWHOIS for all tunnel allocations and services are welcome to use that data.  There was a push for a while from Google in the IETF[1] for an ISP provided location/IP map feed specification, however it looks like that proposal died as it expired over two years ago.

[1] https://tools.ietf.org/html/draft-google-self-published-geofeeds-02

[Napsterbater]

Netflix seems to be blocking he.net IPv6 addresses now.. I'm a US Resident, and I sub to Netflix, and have a tunnel for v6.. Netflix will now show its Proxy/VPN Block message if you connect to Netflix via IPv6 from an HE IPv6 Block, or maybe just ones its associated with the tunnel servers. I also just saw an e-mail on NANOG mailing list about another user having the same issue.

[JRMTL]

Ya just started acting up for me as well. @Napsterbater if you get a response from netflix can you follow up here?

[Napsterbater]

I wasn't planning on it... I know why they are blocking it, and talking to a CSR who has no clue what IPv6 even is isn't gonna help.

The person on the NONOG List contact them and they told him to tell his ISP to remove the VPN they added to his account.... So yeah... He discovered it was the IPv6 after that though.

[yorxnet]

This started happening to me this afternoon. Called Netflix support, and based on that conversation I concluded they consider Tunnelbroker a VPN/Proxy. They're not wrong, but it's still frustrating. Ironically the show I was trying to resume is a Netflix original. I wouldn't have expected that there would be licensing issues on their own content.

I supposed it's time to put more pressure on the ISP for native IPv6 now. Will probably get the same response as usual.

[yorxnet]

Our /32 is registered as part of a US company, and that is the address space being used there. We do not have any IPv6 allocations allocated and designated as "Canada". Our /32 is used globally, as-is. If Netflix has some sort of whitelisting system in place, perhaps the ranges used there can be submitted, if such a whitelist exists, Netflix willing.

According to the Netflix support staff I spoke with, the proxy error was triggered simply because I was seen from Oregon on IPv4, while IPv6 showed your Washington registry information. I'd wager they've assessed your /32 as a tunneling service, and will likely blacklist your block.  :'(

[cdhowie]

Add me to the list of users affected.  I have sent them a few angry tweets.  Sometimes social media can get a company's attention since it's content they can't control, and has a negative PR impact.  I would suggest everyone affected tweet at them with a summary of the problem.

In the meantime, I'm trying to determine if there is a subnet I can block in my FORWARD chain that will kick Netflix over to IPv4, otherwise my only option is to entirely ditch IPv6 (which, of course, is not going to happen).

[yorxnet]

Here's what I came up with for a workaround.

I have an ASUS RT-N66U doing my tunnel duties. It's running DNSMasq which allows for configuration that can override the behavior for domains.

I added "server=/netflix.com/N.N.N.N" to my resolv.dnsmasq file where N.N.N.N is an IPv4 address of a BIND9 DNS host I have control over. This will cause DNSMasq to forward any lookups for netflix.com to that host.

On the BIND9 host I added "filter-aaaa-on-v4 yes;" to the options section of the configuration file.  I then added "filter-aaaa { filter-aaaa-addresses; };" and created an ACL to match that included my ASUS public IP. I also had to enable recursion from my address on the host.

Net result is that when I ask for netflix.com addresses, that request is forwarded on IPv4 to the BIND9 host. When the BIND9 host sees the query on IPv4 it filters out the AAAA responses. The filter-aaaa acl statement is an effort to limit the filtering just to my host specifically.

This was a quick hack that won't likely survive a reboot of the ASUS.

[cdhowie]

yorxnet, that's surprisingly similar to the workaround that I'm developing.

I wrote a tiny DNS forwarder using Twisted Names that will return an empty result for all AAAA queries for netflix.com or a subdomain thereof, and will forward all other requests to my dnsmasq server.  I have tested that the forwarder does what I want using dig, but haven't yet set it up on the network and tested with Netflix.  (About to help with the kid's bedtime routine, standby.)

[cdhowie]

I have tested the server I linked to in my last post, fixed a few bugs, and we are now in business -- I still have IPv6 through HE and I can watch Netflix again.  Hopefully this will be useful to someone else.

[sodre]

This happened to me as well, calling CS was pointless.

Does anyone have a #tag for twitter that we can voice our opinion on?

- P.

[obsessive]

For those of you who are running BSD routers/firewalls, you can null route netflix's ipv6 prefixes. Null routing will send an icmpv6 message back to the device telling them that the host is "unreachable" and the device can then fail over to using ipv4 (assuming you have a dual stack network running ).

I ran the following commands on my firewall:

route add -net 2620:108:700f:: ::1 -reject
route add -net 2406:da00:ff00:: ::1 -reject

And to persist at boot I added the following to the end my /etc/hostname.gif0 file:
!route add -net 2620:108:700f:: ::1 -reject
!route add -net 2406:da00:ff00:: ::1 -reject

After doing this, I can playback netflix just fine on all of my devices now.

Hope this helps someone

[cdhowie]

I ran the following commands on my firewall:

route add -net 2620:108:700f:: ::1 -reject
route add -net 2406:da00:ff00:: ::1 -reject

Just beware that these ranges belong to Amazon Web Services, so you're v6-blocking a whole lot more than Netflix.  That may be okay with you; this is more for others who might consider doing the same thing.