Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

How-To: Un-geoblock Netflix and cast movies to a TV

Sun Mar 06, 2016 4:46 pm

There is now a more up-to-date tutorial available here : viewtopic.php?uid=52264&f=36&t=144309&start=0

[updated several times]

Un-geoblock Netflix and cast movies from a Tablet to a TV with Chromecast

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 post 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 not an expert and 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) ID 7392:7811.
• An SD Card flashed with 2016-02-26-Raspbian-Jessie-Lite (4GB is enough)
• An optional 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 “Master Mode” 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 forth. 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 it 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 (1 only!) 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:

Code: Select all

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

Code: Select all

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.

Next check if Raspbian recognized the WiFi adapter and loaded a driver for it 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.

Nest step, run lsusb to list the USB related devices:
My two WLAN USB adapter types produced this:

Code: Select all

ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

Code: Select all

ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
If you have the first one, you can relax a bit and proceed to the next test. The Ralink one does not work with this setup, although it supports the Master Mode. If you have one, read on, you may be able to get it to work.

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 for 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, but this how-to does not support it, sorry.

Method 2:
(worked only for the Edimax adapter)
To find out if this adapter supports the AP mode, execute this :

Code: Select all

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, 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 hostapd module from Jessie cannot handle the so called managed mode of the WiFi adapter, so we’re going to de-install that (if it is installed already) 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

Code: Select all

sudo apt-get autoremove hostapd
to remove the currently installed package. If it's not installed yet, no problem.

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

Code: Select all

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 an apt-get update/upgrade does not overwrite this special hostapd package, run the following:

Code: Select all

sudo apt-mark hold hostapd
and to remove the lock when you don’t need it anymore:

Code: Select all

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:

Code: Select all

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.

Code: Select all

sudo nano /etc/dhcp/dhcpd.conf
Find the following two lines and comment them out by putting a ‘#’ in front of them.

Code: Select all

#option domain-name "";
#option domain-name-servers,;
Find the line that has authoritative , and make it active by removing the ‘#’ in front of it.

Code: Select all

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 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.0-100. Setting our new subnet in the range is therefore pretty safe.

Do not use the almost standard or range, this is used for just about every private network and may conflict with future things you may want to do with this server. 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.

In simple terms, 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. 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 (otherwise known as the SSID - the public name for the AP), 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

Code: Select all

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

Code: Select all

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:

Code: Select all

Save the file and exit the editor.

4. Installing the Network Interfaces
Now 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.

Code: Select all

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 look like this:

Code: Select all

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.

Code: Select all

sudo nano /etc/dhcpcd.conf
At the very end of the file, add this:

Code: Select all

# 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=
Because wlan0 is going to be the gateway/router, the IP address should be the first address in the subnet, but not 0. The static routers IP address must be the Default Gateway IP address of the main Router 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.

This is the end of part 1
Last edited by paulv on Wed Apr 13, 2016 12:07 pm, edited 29 times in total.

Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sun Mar 06, 2016 5:01 pm

Part 2: [updated several times]

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.
We’re going to edit this file and change a few things.

Code: Select all

sudo nano /etc/hostapd/hostapd.conf
The file should look like this:

Code: Select all

# 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 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:

Code: Select all

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

Code: Select all

to see if the WiFi adapter is setup correctly.

It should look like this:

Code: Select all

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 ifconfig and verify that both interfaces have the proper addresses.
It should say:

Code: Select all

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 off IP conflicts!

6. Setting up the Network Address Translation
The last step before we can start to 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 and filtering.

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

Code: Select all

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:

Code: Select all

# Uncomment the next line to enable packet forwarding for
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 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):

Code: Select all

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 to the bit toilet. 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.

We’ll use a location that is also used by iptables-persistent, which we don’t use, but the location is useful.
First create the configuration file location :

Code: Select all

sudo mkdir /etc/iptables
Now transfer the rules from memory into the configuration file so iptables can be told to boot with these settings later :

Code: Select all

sudo sh -c "iptables-save > /etc/iptables/rules.v4"
If you want, you can look at the results by doing a

Code: Select all

cat /etc/iptables/rules.v4
Time for another test.
Reboot the Pi again. Log in.
Manually load the rules into the iptables memory :

Code: Select all

sudo iptables-restore < /etc/iptables/rules.v4
To check if all went well, run this:

Code: Select all

sudo sh -c "iptables-save > iptables-test"
cat iptables-test
And this should be the result:

Code: Select all

# 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 the lines that start with -A in this 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 and the third all non-default chains.

Code: Select all

sudo iptables -F
sudo iptables -t nat -F
sudo iptables -X
Update the rules file and check it with:

Code: Select all

sudo sh -c "iptables-save > /etc/iptables/rules.v4"
cat /etc/iptables/rules.v4
A rule file after the flushing should look like this:

Code: Select all

# 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 the iptables, start the DHCP server and the host access point daemon, in this order :

Code: Select all

sudo iptables-restore < /etc/iptables/rules.v4
sudo 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 DHCP server is started, I simply added the starting command to /etc/rc.local. Open up the file:

Code: Select all

sudo nano /etc/rc.local
And add the following just before the exit 0 :

Code: Select all

# 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.

The next time you boot the Pi, these processes will now start automatically and correctly.

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 to your home wireless access to the internet without giving out your own SSID and password, you can allow them access through this access server.

In any case, we can also 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. Do not use the new Pi access point at this moment.
Go to the unlocator 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 language 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

Code: Select all

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 change the “new” DNS addresses on the iPAD to those from 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 DNS 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 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 “wanted” 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 iptables 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:

Code: Select all

sudo iptables -I FORWARD --destination -j REJECT
sudo iptables -I FORWARD --destination -j REJECT
Convert them from memory into the rules file.

Code: Select all

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 own 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 the folks from 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.

Last edited by paulv on Wed Mar 30, 2016 2:22 pm, edited 3 times in total.

Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sat Mar 12, 2016 8:01 am

I decided to continue with the VPN portion of the solution in the Networking forum because it's the better home for it.

Here is the link: viewtopic.php?f=36&t=139790


Posts: 2
Joined: Sat Jan 02, 2016 8:16 am

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sun Mar 20, 2016 1:02 pm

Thank you a thousand times for this. I have been trying to create a wireless access point out of my RasPi2 since before Christmas but I was running into the same trouble you were having with all of the guides and tutorials being out of date.
One small thing you may want to edit, when I copied the command to autoremove hostapd I found a tiny typo it says "hostadp". Fix that up and this guide could be followed with just a ton of copy and pasting. It's amazing :)

Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sun Mar 20, 2016 2:31 pm

Oops, I'll fix that!
Thank you for the tip and the compliment!

Posts: 3
Joined: Fri Aug 26, 2016 8:08 am

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Fri Sep 16, 2016 10:56 am

Currently it is not easy to unblock Netflix geo-restricted library due highly restriction of Netflix against VPN users. I have used or try almost 5 different VPNs service provider such as Purevpn, HMA, Expressvpn…ect but buffered vpn is working good, in fact during searching about best vpn for Netflix, I found an article with detail guide where they highlighted buffered VPN and I picked this account after their recommendation, however I am very much satisfy with buffered vpn till now it is working well.

Posts: 1
Joined: Fri Dec 09, 2016 8:25 pm

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Fri Dec 09, 2016 8:34 pm

Thank you for such a detailed post. I spent days trying to get this working via other sources.

On ipchains, do you know how one could whitelist outgoing connections from wlan0? I've had no success getting the rules to hit because it looks like once it matches the POSTROUTING or FORWARD rules then ipchains is done with it.

Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sun Dec 11, 2016 10:25 am

Hi Ida,

Glad this post was useful for you.
Unfortunately, I can't help you with the "whitelisting", I have no experience with that.


Posts: 4
Joined: Fri Apr 22, 2016 6:58 pm

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Wed Jan 25, 2017 8:42 pm

This does it out of the box, sort of:

-- ab1

Posts: 564
Joined: Tue Jan 15, 2013 12:10 pm
Location: Netherlands

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Wed Jan 25, 2017 8:51 pm

No ab1, it's not the same.
Although a nice setup, it is no different than using a commercial VPN setup, and they can be/will be blocked because their IP addresses can be easily found and blocked by the likes of Netflix, as has been done by many other VPN's already.
That happened to me, as you can read in my post.
By setting-up a tunnel to your own, legitimate, IP address, there is simply no way this can be blocked.

Posts: 10
Joined: Mon Jan 30, 2017 7:35 am

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Mon Jan 30, 2017 8:49 am

paulv wrote: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.
That's a nice hack :). A rather, permanent fix. Ever since the NF's crackdown to enforce their geo-blocking, it's been hard to gain access to US region from here. I literally had to get my system configured from ivacy's support. I get where the guys from Netflix are coming from but seriously, i feel sorry for those who can't really find a way around because of their lack of knowledge about technical issues. Techies will work their way around while others end up being ripped by VoDs. Sorry if i got a little carried away.

Posts: 4
Joined: Fri Apr 22, 2016 6:58 pm

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Sat Mar 18, 2017 6:43 pm

On a related note, there is, which is a app running on a Pi to facilitate exactly this sort of thing. It designed to be a turn-key solution, so minimal setup. A subscription is needed to activate the un-blocking features, but you can use it for free in pairing mode, where one Pi connects to the other Pi (friends/family in the US?).

Anyway, you get the idea.

disclosure: I built it.

-- ab1

Posts: 2
Joined: Mon Dec 10, 2018 7:00 am

Re: How-To: Un-geoblock Netflix and cast movies to a TV

Mon Dec 10, 2018 7:02 am

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!
If this is the Pi,
Audio over HDMI:

Return to “Media centres”