Getting Chromecast to work with Unotelly

Few months ago , I bought a Chromecast. It was a nice little device that allowed me to cast stuff from my mobile to my TV. I bought it for my Bedroom TV as I already have an Apple TV for the living room. The main reason why I bought it was to stream Twitch from my mobile phone to the TV. However I wanted Chromecast just to do more in Malaysia. For example with my Apple TV , I am able to watch hulu and netflix , thanks to unotelly. I just want to replicate the same steps , so I changed my DNS to Unotelly DNS in my router. This simple step should work , because all of my computers in the network would automatically use Unotelly DNS – except for Chromecast

So I tried to a simple test whereby to cast Hulu from Mobile App to TV. However I was presented with the ‘Sorry , you can only view in US’. Upon further googling , I found out that Google locks Chromecast with Google DNS. Regardless what is the DNS that was set , it would default to Google DNS.
This poses a problem as I can’t stream Hulu/Netflix and other apps from my phone to the TV. Thankfully , I have stumbled upon a workaround that was written at Server Shares (nice web-site that talks about how to optimize your server to run on tiny little ARM devices)
I am extending his tutorial , because in my network setup – I have IPV6 and it seems Chromecast prefers IPV6 over IPV4. So in this tutorial , I would be including on how to so , which is not covered in the original tutorial 
Credit goes to  Server Shares for the tutorial

  1. You need to have UnoTelly/SmartDNS/Unblock-US (one of those services)
  2. OpenWRT enabled router (it will work with Tomato/DD-WRT , you may have to tweak a bit)

First Step – Assigning a custom DNS server to a client
The first step is to assign a custom DNS server to a client. This is done based on the client’s MAC address. I use Dnsmasq for that. Log in to the router via SSH or telnet and open the file /etc/dnsmasq.conf. At the end of the file, add

# Set cusstom DNS servers for specific hosts
dhcp-host=6c:ad:aa:aa:aa:aa,set:unotelly #Chromecast

To do that , simply fire Terminal (OSX/Linux) or get Putty (Windows). Login to your router IP and then issue
For username and password  , enter the password that you use

nano /etc/dnsmasq.conf

There should be one entry for every device that should use the custom DNS server. For every MAC address, a tag is set. Here ‘unotelly  is used, but this can be any name.
Next go to to Network > Interfaces > Edit LAN > DHCP Server Advanced Settings. In the field DHCP-Options, put


.The tag name should be the same as used above. The IP addresses are the custom DNS servers to use for this client.

To ensure that all clients actually use this order of DNS servers, and no other,
Strict order should be enabled under Network > DHCP and DNS > Advanced Settings
I actually tried this with the latest Chromecast , it does not respect that and it insists on , hence we need to do something more
Second Step – Redirecting Google DNS to UnoTelly DNS
This is the fun part. I have seen guides whereby they force all Google DNS redirects to UnoTelly. I do not want to do in this case , because I trust Google over UnoTelly . Plus I have to use secure web-sites such as banking and all. Hence the way to do this is to force the firewall to redirect requests from Google DNS to UnoTelly
In OpenWRT this can be done in the web interface via Network > Firewall > Custom rules. Add the following rule

# For Chromecast, use Unotelly nameservers
iptables -t nat -A PREROUTING -m mac --mac-source 6c:ad:aa:aa:aa:aa -d -j DNAT --to-destination
iptables -t nat -A PREROUTING -m mac --mac-source 6c:ad:aa:aa:aa:aa -d -j DNAT --to-destination

So what are we doing here , so let me explain , we are using iptables (it’s a linux firewall that says what should I do when I see Mr.Smith , should I lock the door or allow him)  to trick the Chromecast
Ideally we are saying that (like in Little Red Riding Hood) that the Big Bad Wolf is actually the grandmother. In this context , we are saying “You see a Google DNS request from Chromecast , forward it to Unotelly
As far Chromecast thinks , it is actually Google DNS . We have managed to fool it
Be sure to replace the MAC Address and also the unotelly IP Address (to match your region)
Third Step – Saying no to IPV6
Now you can skip this step if you do not have IPV6-enabled in your network. If you do , you’ll have to do something extra
I have IPV6 enabled on my network and I have noticed that Google (and my Android phone) is favoring IPV6 and that messes up everything. So we would have to disable ipv6 at all
There are two ways , one is you can disable IPV6 at your router level but for me this is not an ideal situation , the second option is to take what I have learned from Server Shares and extend it – this is what I exactly did.
So in order to block IPV6 , we would have to use iptable’s bigger brother which is ip6tables. What we would be doing is to block all IPV6 requests coming out from Chromecast. So this forces Chromecast to fall back to IPV4 and it is all set 🙂
In OpenWRT this can be done in the web interface via Network > Firewall > Custom rules. Add the following rule

# For Chromecast, block V6
ip6tables -A INPUT -m mac --mac-source 6c:ad:aa:aa:aa:aa -j DROP

What this will do is it will just block IPV6 request and poof it should work. Hit Apply and all good

One thought to “Getting Chromecast to work with Unotelly”

  1. A variation, if you have a device that is only used for 1 purpose but you can’t guarantee that it will only poll these two known DNS addresses forever, instead of specifying a DNS server, specify a port.
    The chromecast string in the example above would thus be replaced by:
    iptables -t nat -A PREROUTING -m mac –mac-source 6c:ad:aa:aa:aa:aa -p tcp –dport 53 -j DNAT –to-destination
    iptables -t nat -A PREROUTING -m mac –mac-source 6c:ad:aa:aa:aa:aa -p udp –dport 53 -j DNAT –to-destination
    Downside of this example is that you can only specify 1 IP as far as I know for the destination. There is also an assumption that this is DNS and based on port 53 as such. There is nothing stopping a coder of a product from choosing a different port on a different IP to see if it gets a response, but that is the escalation nature of all this. However for today I think the variation might be better for dedicated devices because it will capture all possible DNS server IPs rather than just 2.

Leave a Reply

Your email address will not be published. Required fields are marked *