Show by Label

Sunday, March 6, 2016

How-To: (1)Un-geoblock Netflix and cast movies from a Tablet to a TV

This blog is covering the fact finding and learning experience I went through to make this work. Since then I have published a new version, that is complete, and also uses the systemd way of starting jobs that came with Jessie, rather than the older System V. 

With the advent of Netflix recently clamping down on possibilities to view movies while you are in another country, I started to study how to circumvent this blockage of content I pay for. I’m a Netflix account holder, registered and paying in my home country. I spend several months each winter in a sunny place, and I only want to see the movies and TV-series that are available in my own country, with sub-titles in my own language. I very strongly believe I’m not doing anything illegal. If you are in a similar situation, read on.

This is not for beginners, you should have some experience in working with the Pi, running it head-less and with Raspbian or Debian in general. I will not be able to help you with installation problems, I’m on vacation! So you’re largely on your own! But remember, RTFM and Google is your friend.

There are several steps I went through and in the process learning and trying out the many things to make this work. I am not an expert but I figured it out by going through many instructions and tutorials myself to get the result that I wanted. 

Before we dive in together, let me explain the challenges first and then describe the overall process step by step.

First of all, after many years of doing nothing, Netflix decided to clamp down on the use of VPN’s and Dynamic DNS services, to the point that by the end of February, I could no longer get access to the content I pay for. At the time I was using a VPN service that “tunneled” me from my present location to a local server in my home country. The provider however is leaving me high & dry with this geo-blocking issue so I needed to find another way.

The challenge VPN’s face now is that they can no longer “fake” the location of where you are located to view Netflix anymore. Netflix most likely figured out what IP-addresses were used by the local servers from the VPN companies, and started to block them. Also Dynamic DNS services, used with the same intend to “fake” the actual location are in most cases blocked as well. So, no more Netflix while on the road or on vacation? I don’t think so!

The ultimate setup that will be free from a Netflix geo-block is to have a private VPN that will use a tunnel from your location to the router in your home. That is what I will work on next, but while I’m on vacation, I can’t set my router up for that. 

The solution that I’m describing below will be needed with the ultimate solution as well, it just needs to be extended with a VPN client.

To view Netflix on the TV in my holiday apartment in a convenient manner, I use an iPad with the Netflix app to select and play the movies. I use a Google Chromecast 2 to cast the movies and sound to the TV. The iPad also acts as the remote. 

Even though I can quite easily get the iPAD to circumvent the geo-block, the Chromecast will spoil the party. Of course I could use my PC, but then I need to move that around to connect it to the TV through an HDMI kabel, but, annoyingly, I don’t get the sound to play on the TV, or need to use another additional audio kabel. Yuck!

So to continue my current viewing pleasure, I faced three challenges.

  1.  I needed to find a way to circumvent the geo-block for Netflix.
  2. The Google Chromecast has a similar issue. The Google DNS addresses are hard-coded into this device, and if Netflix movies are casted to the Chromecast, to show movies on a TV, the Netflix geo-lock gets activated.
  3. The modem/router in the apartment we are in is closed. I cannot access it, I only know the SSID and the password for the wireless part. It does have 4 LAN connections though.

So how did I solve this. 
Well, I turned my Pi into a wireless access point, so both my iPAD with the Netflix app and the Chromecast could connect to it. I used the firewall features (iptables) of the Pi to redirect the traffic from the wifi adapter to the internet through a LAN connection to the modem/router. I also used iptables to block the DNS requests coming from the Chromecast, so it would revert to the ones I supply. Because I do not have my own VPN yet, I’m using a Dynamic DNS service provider that is still able to provide a geo-unblock, and they are working hard to continue to provide that even when Netflix bores down on them.

I use the following list of equipment, parts and services:
  • A Raspberry Pi (I still use the now “classic” Model (1) B)
  • A USB WiFi Adapter (I use the Edimax Wireless 802.11b/g/n nano USB adapter) it can also be identified as an RTL8188 / RTL8192cu / EW-7811un.
  • An SD Card flashed with 2016-02-26-Raspbian-Jessie-Lite (4GB is enough)
  • An HDMI cable. Access to the Raspberry is headless, no keyboard required, but it does help if you can connect the Pi to a TV to see the boot process.
  • An iPAD with the Netflix app to control the movies.
  • A Google Chromecast 2 to cast the movies from the iPAD to the TV, and that also gets me the sound to play through the TV set.
  • A subscription for a Dynamic DNS service ( (free for 3 days)
  • A LAN cable to connect the Ethernet port from the Pi to the local router/modem.
The most important and crucial devices for success on this list is the right USB WiFi Adapter and an unblocking service that (still) works. As a minimum, get a WiFi adapter from the Pi approved list, and if you can, get the Edimax one I use. The best way is to use an adapter that you know already works with the Pi in your environment, before attempting to use it in our special setup. The crucial feature we need for the adapter is the “managed” mode.

Before you get started, you should realize that this is not a 5 minute job. You should at least expect to spend 1-2 hours on the whole setup process.

Where possible, I put all the commands and data to be used in the process in a form that lets you do a copy and paste from this post to the Pi. It helps to cut down on typing errors.

1.   Getting Debian-Jessie-Lite setup on the SD card

Do not attempt to do this install on your current SD card setup. Use a separate card for this setup. It allows you to quickly switch cards from your daytime Pi stuff to your evening couch-surfing activity without the headaches of changing things back and force. Even if you will use a dedicated Pi, start with a new install of the latest Raspbian.

There are enough examples on how to get Raspbian on an SD card, I’m not going to cover that. I selected Jessie-Lite for this project. It does not have the bloat-ware that I don’t need for this application, and it fits easily on a 4GB SD card. Just about any decent and good quality card will do, speed is not important. The same is true for the Pi, the classic model B is fast enough and has all we need.

As soon as you have copied 2016-02-26-Raspbian-Jessie-Lite (or a later version) on the SD card, I suggest that you stick it (back) into your PC and edit the cmdline.txt file that is in the partition Windows can access. At the very end of the single command line, add an IP address. To find out what IP address range you probably should use, go to the command line interface on your PC and run ipconfig.  It will show you the IP address of your PC, so select one that is reasonably close and add that to the cmdline.txt. I use “ip=”. Write down the Default Gateway IP address, you’ll need that later.

This will give you the opportunity to SSH into the Pi after the first boot and control it from there.
Put the SD card into the Pi, connect the USB WiFi adapter in a free USB slot, connect the Pi to a free port on the modem/router with a LAN cable and start the Pi up.

Using SSH on your PC, log in with user pi, password raspberry. Then run the setup program:
sudo raspi-config

Go through the following options:
            - expand file system
            - change user password (pick a good one!)
            - set the international options (language, timezone, wifi country)
            - in the advanced options, set the hostname and set the memory split to 16MB

Finish and reboot.

Then login with pi and the new password, and run
sudo apt-get update; sudo apt-get upgrade

At this moment, you should have a fully functioning Pi with an Ethernet connection to the internet. If not, make that work first before you go to the next step.

Now check if Raspbian recognized the WiFi adapter and loaded a driver automatically. Run “iwconfig” to see if it did. Don’t worry about missing items, we just want to see if Raspbian recognized the hardware and loaded a driver for it. If not, you may have a device that is not supported. Get this fixed before you move on.

Run “lsusb” to list the USB related devices:

My two WLAN USB adapters produced this:
ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

How to test if your WiFi adapter supports the Master Mode.
This step is crucial and you can only continue when you have success with the following tests.
If the driver for the WiFi adapter was indeed loaded, you can now check to see if the so called Master Mode is available for your device. 

I have found that there are two possibilities, unfortunately, they are both mutually exclusive. You have to try one or the other:

Method 1:

(worked only on the Ralink adapter)
Run “iw list”, and look for the section called “Supported interface modes:” check if you have AP and/or AP/VLAN listed. AP stands for Access Point, so if you do have that listed, great, you can continue. 
But you need to install another hostapd version. If you get no result whatsoever from the “iw list  command you can try the next method.

Method 2:

(worked only on the Realtek / Edimax adapter)
Another method to find out if the adapter supports the AP mode is by executing this :

sudo iwconfig wlan0 mode master   

If there is no error, celebrate and continue.

If both methods do not give you the expected result, chances are that you may be out of luck. You can still give it a try though. The issue is going to be with the hostapd we're going to install next.
The Master Mode is essential because instead of using the WiFi adapter as a “client”, we are going to set it up as an Access Point, like and next to the one that your modem/router already provides.

To continue the setup, we’re going to need a few additional or different software pieces to make this work. First of all, we’re going to need hostapd (host-access-point-daemon), which is a daemon that helps us to setup an access point with WPA-2 security, so a client will have to use the SSID and a PK (password) to connect. Just like your modem/router needs right now.

2.   Installing a Host Access Data Point (hostapd)

The already installed hostapd module from Jessie cannot handle the so called managed mode of the WiFi adapter, so we’re going to de-install that and get a better one instead. 

If you have the Ralink adapter, you need to install the hostapd that works with that particular adapter. It seems that the standard hostapd package may support it. Try that.

I’m not going to cover that installation here, sorry! But you may be able to follow along with what I’m doing next. Note that here is one additional file you need to edit : /etc/default/hostapd, and make sure it contains this: DAEMON_CONF="/etc/hostapd/hostapd.conf" .
If you can make it work, let me know and I can update this post.

Continuing with the Realtek / Edimax adapter.

Thankfully, Jens Segers, a smart guy from Belgium, has configured the hostapd portions that are supplied by REALTEK, the manufacturer of the WiFi USB adapter, and configured the various source pieces so it works on our Pi.

First we run
sudo apt-get autoremove hostapd  
to remove the currently installed package.

Then run the following commands to get, compile and install the new hostapd code from Jens:

tar -zxvf v2.0.tar.gz
cd RTL8188-hostapd-2.0/hostapd
sudo make
sudo make install

The “sudo make” will compile and link all the sources and will run a while, so be patient. Don’t worry about the warnings. When the make has finished, use “sudo make install” to put the new pieces in their right place. 

To make sure that a next apt-get upgrade/update does not overwrite the special hostapd package, run the following to hold off updates:

sudo apt-mark hold hostapd

and to remove the lock when you don’t need it anymore:

sudo apt-mark unhold hostapd

3.   Installing and setting up a DHCP server

Because we’re going to run the Pi as a server, the next piece we need is a DHCP server to provide the connecting clients to the Pi with IP addresses. The package we need is called isc-dhcp-server. ISC stands for the Internet Systems Consortium, and they maintain this package.
You can install this package with:

sudo apt-get install isc-dhcp-server

There are two configuration files /etc/dhcp/dhcpd.conf and /etc/default/isc-dhcp-server which we will need to configure.

sudo nano /etc/dhcp/dhcpd.conf

Find the following two lines and comment them out by putting a ‘#’ in front of them.

#option domain-name "";
#option domain-name-servers,;

Find the line that has authoritative , and make it active by removing the ‘#’ in front of it.


Now we need to setup the DHCP server with the information for our access point.

First of all, we need to decide a couple of things. We are going to provide our own sub-net for the clients that connect to our access point. The IP address pool our server will use should be different from the one the modem/router is using. The gateway IP address of my modem/router is, so the subnet starts somewhere in the 100 range. Because I do not have access to the router, I don’t know how large the range of addresses is that it can assign, so I’m assuming from 100-199. Setting our new subnet in the 200 range is therefore pretty safe. 

Do not use the very much used range, this may conflict with future things you may want to do. The first couple of addresses will be reserved for our Pi server, so we’ll tell DHCP to give out addresses to clients from until (called the pool). Ten addresses is more than enough, if you need more, expand the range.

When a client requests access, the DHCP server assigns an IP address with a lease time in between the min-max range, regardless of what the client requests. The numbers are in seconds. In simple terms, when half the lease time has expired, the server is going to ask the client to re-confirm the lease and give it a lease extension, or it eventually re-claims the IP address to give it out to new clients. Google “dhcp lease time” for more information. 

You can give your Pi a domain name, use whatever you want, but be careful with special characters and spaces. If in doubt, Google it. Talking about Google, we’ll initially set up our access point to pass on DHCP requests to the Google public DNS servers so we can test things. Later on we’ll change that. The option routers IP address must be the lowest IP address of the subnet, but not 0.

Go to the end of the dhcpd.conf file and add this by copy & paste: 

subnet netmask {
 option broadcast-address;
 option routers;
 default-lease-time 600;
 max-lease-time 7200;
 option domain-name "My-GW";
 option domain-name-servers,;

Don’t forget to change the domain-name before you move on.
Save the file and exit the editor.

The next file to edit is that of the isc-dhcp-server configuration.

sudo nano /etc/default/isc-dhcp-server

In this file we’re going to define what interface we want to setup the service for. Change the interfaces statement to read:


Save the file and exit the editor.

4.   Installing the Network Interfaces

Here we’re going to assign a static IP address for the WiFi adapter and the Ethernet interface. 

Pre-Jessie we would do that in /etc/network/interfaces, and setup the SSID and password for the wireless interface in /etc/wpa_supplicant/wpa_supplicant. Things have changed however.

You first need to edit /etc/network/interfaces and disable the supplicant setup for the wlan0 interface.

sudo nano /etc/network/interfaces

To disable the supplicant setup for wlan0, commenting out /etc/wpa_supplicant/wpa_supplicant  (put a “#” in front of this line).
The wlan0 section should now look like this:

allow-hotplug wlan0
iface wlan0 inet manual
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Save and close the file.

In Jessie, the major work will be defined in the dhcpcd (dhcp-client-daemon) configuration file.

sudo nano /etc/dhcpcd.conf

At the very end of the file, add this:

# Static IP configuration for eth0
interface eth0
static ip_address=
static routers=
static domain_name_servers=
# static IP configuration for wlan0
interface wlan0
static ip_address=

The static routers IP address must be the Default Gateway IP address you wrote down earlier.

This will also define the proper IP address for the LAN interface, the one we previously set in the /boot/cmdln.txt file. Make sure it’s the same address in both files. The ending of the IP addresses with “/24” is the equivalent (and shorthand way) of adding a mask.

5.   Setting up hostadp

We’re now going to setup the hosting part of the wireless network by configuring the freshly compiled and installed hostapd configuration file.

sudo nano /etc/default/hostapd

In this file, there is a reference to another configuration file that needs to be included in the setup. Make sure this line is present, or make it such


Save and close the file. Now we’re going to edit this file and change a few things.

sudo nano /etc/hostapd/hostapd.conf

The file should already look like this:

# Basic configuration
# WPA and WPA2 configuration
wpa_passphrase= My_passphrase
# Hardware configuration

There is one item you should change, one you must, and one you could.
You should change the SSID name into something more meaningful then “My_AP”, so you can find the server name in between all the other SSID’s that show up on the WiFi network access list. Make sure it’s the same name you assigned in the dhcpd.conf file earlier!

You must change the My_passphrase into a strong password. Remember that everybody can see your SSID and try to log in. Although the wireless range of the adapter is limited, maybe only one large room size, you should be careful.

You could change the wifi channel parameter, based on what channels the surrounding servers use, to minimize interference conflicts. (select 1, 6 or 11)

Save and exit the editor.

It’s now time to re-boot and see if everything is OK at this point.

After you rebooted, log in again. 

To check if the Ethernet and the WiFi interfaces are set-up correctly, run the following commands in this order:
sudo service hostapd start
sudo service isc-dhcp-server start
If there are errors, you need to double check the configuration files carefully and also check the network settings.
You can run the same commands with “
status  instead of “start” to get some diagnostic information.

If there are no errors, run


to see if the WiFi adapter is setup correctly.

It should look like this:

wlan0     unassociated  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency=2.437 GHz  Access Point: Not-Associated
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Look for the Mode, it should say Managed
The Access Point: should still be
Not Associated at this moment

Then run


and verify that both interfaces have the proper addresses.

It should say:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:cb:d6:ea
          inet addr:  Bcast:  Mask:

wlan0     Link encap:Ethernet  HWaddr 80:1f:02:b6:99:5e
          inet addr:  Bcast:  Mask:

If you want, you can now edit /boot/cmdline.txt and remove the IP= portion from the statement. It is no longer needed, but does not cause any harm, unless you change the static address. 

Be aware of IP conflicts!
6.   Setting up the Network Address Translation

The last step before we can start to actually use the access point is setting up a configuration that tells the system what to do with the incoming data and where to send it to. This will allow us to accept requests from the iPad and Netflix app, and manipulate them before we pass it on to the modem/router to go into the wild internet.
This process is called Network Address Translation or NAT.

We’re going to change the configuration setup and tell the system to forward all packets from the wlan0 interface to the eth0 interface.

sudo nano /etc/sysctl.conf

Look for the line that says net.ipv4.ip_forward and remove the hash in front. It should now look like:

# Uncomment the next line to enable packet forwarding for IPv4net.ipv4.ip_forward=1

Save and close the file.

7.   Setting up the Firewall

We are now going to use the Debian firewall and make it do some interesting things. The firewall is also called iptables, and this is a very powerful and flexible piece of software. It’s not easy to understand, looks intimidating at first but I will briefly show what you need to do and explain it a bit. There are some interesting explanations and tutorials that I went through to learn about this feature. Google is your friend once again.

Basically we are telling iptables what we want it do to with the information coming in from the clients to the wlan0 interface and how and also what to send to the eth0 interface.

At first we are going to define the forwarding bits for the router. Later we will add some more statements to fool the Netflix and Chromecast’s DNS requests.
I’m recommending a simple method to work with iptables.
Just cut & paste these lines to execute them on the Pi (the second one is one large line, no break):

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT

These three statements will tell the firewall to pass on anything coming from the wlan0 interface, and pass that on to the eth0 interface.
Here is something you should know. The results are now loaded into the iptables run-time memory. A reboot will flush them again. To make them “stick”, we need to put them into a file that will be read and loaded at startup. To do that you need to execute the following two steps. 
First save the original configuration file:

sudo cp /etc/iptables/rules.v4 /etc/iptables/rules.v4.orig

Now transfer the rules from memory into the configuration file so iptables will boot with these settings from now on:

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

If you want, you can look at the results by doing a

cat /etc/iptables/rules.v4

Time for another test. Reboot the Pi again. Log in.

Manually load the rules into the iptables memory:

sudo iptables-restore < /etc/iptables/rules.v4

To check if all went well, run this:

sudo sh -c "iptables-save > iptables-test"
cat iptables-test

And this should be the result:

# Generated by iptables-save v1.4.21 on Sat Mar  5 15:09:18 2016
:PREROUTING ACCEPT [2322:147094]
:INPUT ACCEPT [65:9939]
:OUTPUT ACCEPT [63:8936]
# Completed on Sat Mar  5 15:09:18 2016
# Generated by iptables-save v1.4.21 on Sat Mar  5 15:09:18 2016
:INPUT ACCEPT [5093:417105]
:OUTPUT ACCEPT [2374:271599]
-A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan0 -o eth0 -j ACCEPT
# Completed on Sat Mar  5 15:09:18 2016

If you have these bold lines in your report, they are proof that the 3 rule settings were added at boot time. In that case, you can jump to the next topic.

If you made a mistake, you can start all over again by deleting all rules (called flushing in iptable speak) or copy the saved rules file back. Note that there are two sets of rules we will be using. You need to flush both. The first one flushes filter rules, the second one NAT rules.

sudo iptables -F
sudo iptables -t nat -F

Update the rules file and check it with:

sudo sh -c "iptables-save > /etc/iptables/rules.v4"
cat /etc/iptables/rules.v4

A rule file after the flushing should look like this:

# Generated by iptables-save v1.4.21 on Sun Mar  6 10:12:33 2016
:INPUT ACCEPT [530:42519]
:OUTPUT ACCEPT [213:25942]
# Completed on Sun Mar  6 10:12:33 2016
# Generated by iptables-save v1.4.21 on Sun Mar  6 10:12:33 2016
# Completed on Sun Mar  6 10:12:33 2016

And start again. This time, execute one line at a time and check for errors.

8.   Starting all the Components

With all the basics set up, we can now start the two processes that will turn your Pi into a wireless access router.

Execute the following commands to load iptables, start the host access point daemon and the DHCP server in this order:

sudo iptables-restore < /etc/iptables/rules.v4sudo service hostapd start
sudo service isc-dhcp-server start

If you now go to your PC, iPhone, iPad or other wireless device and look at the wireless networks, you should see the SSID of the one you created. Select it, and type in the password. After a short period, you should be accepted and should have internet. Try it out by going to a browser and select a website.

Now go to your Netflix app on the Pad, and start that up. After you signed in, it should work normally, but you should still only get the content of the country you are in, because we’re not done yet. At this moment we’re just checking everything we’ve done up until now.

If this was successful, we want to make sure both processes will start at boot time from now on. You normally do this by installing them in the boot process. However…I’m having a startup order problem with Jessie.

First of all, I found that the automatic starting of the isc-dhcp-server is a bit tricky.  It will only start if both interfaces are up, and in my configuration, that does not seem to be the case. Also, the hostapd must be running before isc-dhcp-server will start without an error. I suspect there is a “race” somewhere, that prevents the automatic start at boot time. I tried, but cannot solve it the “proper” way. If you do know how to solve this, chime in so I can fix it.

To make sure that both eth0 and wlan0 are up before the hostapd and DHCP server is started, I simply added the critical starting commands to /etc/rc.local. Open up the file:

sudo nano /etc/rc.local

And add the following just before the exit 0 :

# start the access point packages here so everything will start in order
printf "Reloading iptables"
iptables-restore < /etc/iptables/rules.v4
sleep 1
printf "Starting hostapd"
service hostapd start
sleep 1
printf "Starting the DHCP server"
service isc-dhcp-server start

Save and exit the editor.

Now that all the groundwork is in place, we have a fully functional and general purpose wireless access point. You can use this when all you have is a router with a LAN interface, but no wireless. You will still find this a lot in hotels and apartments. Also, if you want to give visitors wireless access to the internet without giving out your own SSID and password, you can allow them access through this access server.

Now that all the groundwork is in place, we can finally start to address the real challenge.

9.   Getting Around the Geo-Restrictions

The last and final step is bypassing or fooling DNS requests from both Netflix and Chromecast so we can circumvent the dreaded geo-blocking.

First of all, you need to subscribe and install a software application that will help us to do this. After trying several packages and looking at a lot more, I settled on using a Dynamic DNS service from From the other ones I tried I found that after a few days they were no longer able to provide their service after Netflix started to target their services. Unlocator still works, and they are adamant on the continuation of this service, unlike several of the other ones I tried or looked at. Their software is free for 3 days, and you don’t need to send them credit card information to get started.

Use your iPAD while logged in to the modem/router to do theinstallation. 
Do not use the new Pi access point at this moment. 

Go to the unlocater website and get the free trial set up. In the process, you will get two DNS IP addresses. Go ahead and setup your iPAD with them, but make a note of the DNS addresses you had before. They came from the modem/router. Also make sure you set the country location to where you want “to be”. They have easy to follow instructions on the website. 

After you installed the new DNS addresses for your mode/router SSID, and you get the “green lights” from the website, try Netflix again. Verify that you will now be able to view the local content in the local langue and with local language sub-titles. This works and is all nice if you only want to play this on your iPAD, but we really want to cast it to the TV.

Here is where our Pi access point and router comes in. We are going to replace the Google public DNS servers ( and that we used in the configuration now with the DNS server addresses you got from unlocator.

To do this, you need to edit the following two DHCP configuration files.

sudo nano /etc/dhcp/dhcpd.conf
sudo nano /etc/dhcpcd.conf

Note that in the first file, a comma separates the two DNS addresses, while in the second file you only need a space. 

With this done, you should reboot the Pi again.

After the reboot you can now use your iPAD or any other wireless device with a Netflix app, to log in to the new access point on the Pi router and enjoy Netflix “in” your home country.

If that test works, I suggest you revert the “old” DNS addresses on the iPAD to your original modem/router SSID back to what they were. This allows you to switch back and force between the two SSID’s or wireless access points.

OK, now we need to address the Chromecast device DNL issue. But first I suggest you run a little test and get a demonstration of the interaction between Netflix and the Chromecast that will reinstate the geo-blocking again.

While your iPAD is showing a "local" Netflix movie on its screen, cast it now to the TV by using the Chromecast. You’ll notice immediately that you will have lost the content in your “local” country, and are back into the local country offerings and settings. This is caused by the Chromecast. As soon as the Netflix app sees the public Google DNS requests coming from the Chromecast, it will revert back to the local content and you are back to square one.

As I mentioned in the beginning, you cannot change the DNS IP addresses for the Chromecast, because they are hard-coded in the firmware.

We’ll use the Pi firewall or iptable to get around that. If you Google around, you will see many different solutions that are all trying to solve this issue. Some are really complex. Unfortunately, I found that most of them do not really work or work well. I ended up using a set of rules that take advantage of the way DNS servers actually work. If a DNS service is requested, and the programmed DNS server is not answering, it will revert to the next available DNS server, and if that is not available it will again go to the next, until it gets an answer.

So with the following two iptable filter instructions, we simply filter for all requests for the two public DNS servers from the Chromecast and let them go to bit heaven by bluntly rejecting them. Eventually the Chromecast will get answers so it’s happy, but does not know that we fooled it.
Execute the following by cutting & pasting to your Pi:

sudo iptables -I FORWARD --destination -j REJECT
sudo iptables -I FORWARD --destination -j REJECT

Convert them from memory and add them to the rules file.

sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Now we need to instruct Chromecast to use our new wireless access point on the Pi so it will get the DNS treatment. 

You do that by pressing the tiny reset button on the Chromecast2 device for a few seconds. It will then perform a factory restart followed by the setup procedure. This time however, you are going to instruct it to connect to your Pi wireless access point, and set the password. If it all went well, you can now select the TV as the casting target and it should compete the setup. When that is successful, it will tell you it is connected to your Pi, and the internet and will start to show the nice background pictures.

Go back to your iPAD, make sure you are using the Pi access point router SSID, and then kill and restart the Netflix app. You can now start the Netflix app again and log in to your Netflix account. 

You will already see that you get your home country selection. Select a movie, and also select the local language elements like sub-titles or language. Start the movie and cast it to the TV. If all went well, you will see the sub-titles and hear the local language as if you were couch surfing at home.

Congratulations are in order if you were successful the first time ‘round! 

My experience with this setup is very good, I’m satisfied, although I have only the minimum internet speed (10MB down, 1Mb up).  I have not seen a single stutter and the resolution is very good.

You have to realize that this will only work as long as can stay ahead of the game, but I have confidence they will. Otherwise, you’ll need to find a solution that still works, or has found a way to beat the Netflix geo-block police gang.

This summer I will finish the work on the private VPN solution, and I will post that here too.


No comments:

Post a Comment