Confirming Chromecast is blackholed/sinkholed

Help
20

If the device has a DNS IP hard coded into it, it won't use any DNS provided by the router. The router can tell the device that Pi-Hole is your DNS, but the device will ignore it.

This is not related to any function of a cable modem, unless the modem includes a router with ti.

Some routers have a firewall capability where you can redirect DNS traffic to Pi-Hole. If any device is trying to use Google DNS instead of Pi-Hole, the router will see these DNS requests coming from the device to Google, and will redirect those requests to the Pi-Hole.

21

I have an Arris cable modem. Earlier in this thread you can see screenshots of me specifying the Pi Hole as the DNS. I also showed the static route and iptables command to sinkhole 8.8.8.8 and 8.8.4.4. But nslookup using 8.8.8.8 always resolves the external address. Clearly the Pi Hole is working but I can't prove Google DNS is being dropped.

22

Were the iptable rules set set on the router or the Pi?

23

The Pi. The Arris has some preset firewall options with little room for customization.
Edit: here are some of the Arris firewall options, customer to Medium, as High wouldn't fit in the screenshot:

25%20PM
25%20PM425×655 42.9 KB

24

Having iptables on the Pi to block network traffic to alternate DNS servers is not going to be effective. The DNS traffic only goes to the Pi (Pi-Hole) if the client has the DNS address. If not (i.e. hard coded to use another DNS), then the requests go directly from the client to the router and off to the internet, and the Pi (Pi-Hole) sees none of it.

For a DNS redirector to be effective, it has to be on the router (the only piece of equipment in your setup that sees all the traffic to the internet).

25

But here are my Arris DNS settings, pointing to 192.168.0.2, the Pi Hole

51%20PM 37%20PM 53%20PM

26

If the client receives its DNS assignment from the router, this will send the traffic to Pi-Hole. However, if the client is hard coded with a DNS, it will ignore any DNS setting it receives from the router and will use the hard coded DNS (and bypass Pi-Hole).

27

Even though I sinkhole the hard coded Google DNS addresses?

Wouldn't it be like this?
Chromecast --> Arris --> Pi Hole --> Google DNS sinkhole --> alternate DNS provided by Pi Hole?

How can the Chromecast --> 8.8.8.8, if the Arris --> Pi Hole --> Google DNS sinkhole?

28

No. Since the client has the hard-coded DNS in it, it will go from Chromecast -> Arris -> hard-coded DNS and completely bypass Pi-Hole. If the client already has 8.8.8.8 coded in it, it won't do any kind of DNS resolution locally, since it already has the IP it needs.

29

So what do you think the Blocked Services option is doing? It only applies to devices that have the Pi explicitly set as DNS? And there doesn't seem to be much flexibility in the Custom Firewall setting either.

And I did a Wireshark capture up above and only see multicast traffic. Why would I see that and not Google DNS?

Thanks for letting me be a bit verbose here. It might help someone else down the line.

I've let RCN know via Twitter and email to provide more flexibility but I'm not holding my breath.

30

I do not know.

31

I have a chromecast, DHCP provides the DNS server (pihole), but the chromecast simply ignores the DHCP provided DNS server.

This is what happens if I simply power on the chromecast, up to the moment the first picture appears on screen (chromecast IP 192.168.2.131):

image
image3705×1371 389 KB

As you can see, the chromecast simply ignores the DHCP provided DNS server and uses the hardcoded 8.8.8.8 (google DNS server).

Because I have a NAT rule on the firewall, everything going to 8.8.8.8 is redirected to the pihole. The rule applies to all devices on the WIFI adapter and the destination is NOT the pihole (192.168.2.57). Some other devices are actually using the DHCP provided DNS settings, so redirection is NOT required.

image
image2562×327 28.7 KB

Warning !!! In this example, the pihole is on a different physical network (wired - ethernet), this rule will NOT work if you are using pihole on WIFI. The pihole will NOT be able to resolve DNS requests.

As a result, the firewall intercepts all DNS requests from the chromecast and redirects them to the pihole. In the pihole log (/var/log/pihole.log) the following entries are logged, proving the DNS requests are redirected:

May  5 11:27:08 dnsmasq[8769]: query[A] clients1.google.com from 192.168.2.131
May  5 11:27:08 dnsmasq[8769]: forwarded clients1.google.com to 127.10.10.2
May  5 11:27:08 dnsmasq[8769]: reply clients1.google.com is <CNAME>
May  5 11:27:08 dnsmasq[8769]: reply clients.l.google.com is 172.217.20.110
May  5 11:27:09 dnsmasq[8769]: query[A] time.google.com from 192.168.2.131
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 216.239.35.12
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 216.239.35.0
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 216.239.35.4
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 216.239.35.8
May  5 11:27:09 dnsmasq[8769]: query[AAAA] time.google.com from 192.168.2.131
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 2001:4860:4806:c::
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 2001:4860:4806:4::
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 2001:4860:4806:8::
May  5 11:27:09 dnsmasq[8769]: cached time.google.com is 2001:4860:4806::
May  5 11:27:09 dnsmasq[8769]: query[A] connectivitycheck.gstatic.com from 192.168.2.131
May  5 11:27:09 dnsmasq[8769]: forwarded connectivitycheck.gstatic.com to 127.10.10.2
May  5 11:27:09 dnsmasq[8769]: reply connectivitycheck.gstatic.com is 172.217.168.195
May  5 11:27:14 dnsmasq[8769]: query[A] tools.google.com from 192.168.2.131
May  5 11:27:14 dnsmasq[8769]: cached tools.google.com is <CNAME>
May  5 11:27:14 dnsmasq[8769]: forwarded tools.google.com to 127.10.10.2
May  5 11:27:14 dnsmasq[8769]: query[AAAA] tools.google.com from 192.168.2.131
May  5 11:27:14 dnsmasq[8769]: forwarded tools.google.com to 127.10.10.2
May  5 11:27:14 dnsmasq[8769]: reply tools.google.com is <CNAME>
May  5 11:27:14 dnsmasq[8769]: reply tools.l.google.com is 172.217.17.78
May  5 11:27:14 dnsmasq[8769]: query[A] mtalk.google.com from 192.168.2.131
May  5 11:27:14 dnsmasq[8769]: cached mtalk.google.com is <CNAME>
May  5 11:27:14 dnsmasq[8769]: forwarded mtalk.google.com to 127.10.10.2
May  5 11:27:14 dnsmasq[8769]: reply tools.google.com is <CNAME>
May  5 11:27:14 dnsmasq[8769]: reply tools.l.google.com is 2a00:1450:400e:80a::200e
May  5 11:27:14 dnsmasq[8769]: reply mtalk.google.com is <CNAME>
May  5 11:27:14 dnsmasq[8769]: reply mobile-gtalk.l.google.com is 108.177.127.188
May  5 11:27:14 dnsmasq[8769]: query[A] www.gstatic.com from 192.168.2.131
May  5 11:27:14 dnsmasq[8769]: forwarded www.gstatic.com to 127.10.10.2
May  5 11:27:14 dnsmasq[8769]: reply www.gstatic.com is 172.217.17.35
May  5 11:27:16 dnsmasq[8769]: query[A] clients3.google.com from 192.168.2.131
May  5 11:27:16 dnsmasq[8769]: forwarded clients3.google.com to 127.10.10.2
May  5 11:27:16 dnsmasq[8769]: reply clients3.google.com is <CNAME>
May  5 11:27:16 dnsmasq[8769]: reply clients.l.google.com is 172.217.20.110
May  5 11:27:18 dnsmasq[8769]: query[A] ajax.googleapis.com from 192.168.2.131
May  5 11:27:18 dnsmasq[8769]: forwarded ajax.googleapis.com to 127.10.10.2
May  5 11:27:18 dnsmasq[8769]: query[A] fonts.googleapis.com from 192.168.2.131
May  5 11:27:18 dnsmasq[8769]: forwarded fonts.googleapis.com to 127.10.10.2
May  5 11:27:18 dnsmasq[8769]: reply ajax.googleapis.com is <CNAME>
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 172.217.17.138
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 172.217.168.202
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 172.217.17.42
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 172.217.168.234
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 172.217.20.106
May  5 11:27:18 dnsmasq[8769]: reply googleapis.l.google.com is 216.58.211.106
May  5 11:27:18 dnsmasq[8769]: query[A] ssl.gstatic.com from 192.168.2.131
May  5 11:27:18 dnsmasq[8769]: forwarded ssl.gstatic.com to 127.10.10.2
May  5 11:27:18 dnsmasq[8769]: reply ssl.gstatic.com is 172.217.17.131
May  5 11:27:18 dnsmasq[8769]: reply fonts.googleapis.com is <CNAME>
May  5 11:27:18 dnsmasq[8769]: reply googleadapis.l.google.com is 172.217.19.202
May  5 11:27:20 dnsmasq[8769]: query[A] fonts.gstatic.com from 192.168.2.131
May  5 11:27:20 dnsmasq[8769]: forwarded fonts.gstatic.com to 127.10.10.2
May  5 11:27:20 dnsmasq[8769]: reply fonts.gstatic.com is <CNAME>
May  5 11:27:20 dnsmasq[8769]: reply gstaticadssl.l.google.com is 172.217.20.99
May  5 11:27:20 dnsmasq[8769]: query[A] lh5.googleusercontent.com from 192.168.2.131
May  5 11:27:20 dnsmasq[8769]: cached lh5.googleusercontent.com is <CNAME>
May  5 11:27:20 dnsmasq[8769]: forwarded lh5.googleusercontent.com to 127.10.10.2
May  5 11:27:20 dnsmasq[8769]: reply lh5.googleusercontent.com is <CNAME>
May  5 11:27:20 dnsmasq[8769]: reply googlehosted.l.googleusercontent.com is 172.217.17.33

pihole-FTL forwards the request to unbound (127.10.10.2), unless of course the entry is cached OR blocked

You can also capture the DNS requests on the raspberry pi, by using the command sudo tcpdump -s0 -w /home/pi/pi.cap. The resulting file can be opened with wireshark, but it will also contain all the DNS requests unbound is making to resolve the DNS request, witch will make it much harder to read and match the chromecast requests to the pihole requests.

32

So is my only option of get something like Firewalla? When I power up the Chromecast all I see is the multicast traffic.

Edit: uploaded the suggested tcpdump, the Chromecast IP is 192.168.0.109, once again only traffic to 224.0.0.251, after power cycling the Chromecast except for this one to the Pi:
106 42.127729 192.168.0.109 192.168.0.2 DNS 75 Standard query 0xf2e3 A www.gstatic.com

23%20PM
23%20PM1161×62 23.2 KB

33

Where is your WIFI access point in your network layout? A firewall with NAT (I don't know if Firewalla has this option) is only usefull if the outbound traffic needs to go trough the firewall. Since your chromecast is on the same subnet as your PI, this would suggest you're either using only WIFI in your network OR you're using something like a WIFI repeater on you're wired network OR your cable modem also provides WIFI.

Draw us a picture of your network, as detailed as possible. You can use this site to draw a network layout online and copy / paste the layout in discourse.

34

I'll draw a picture shortly but the Arris cable modem provides the wifi and the Pi is connected intoa port of the Arris.

35

If the Arris cable modem isn't NAT capable, you will never be able to get the redirection working. Every WIFI device, getting it's IP from the Arris cable modem, that tries to reach 8.8.8.8, will always know the shortest route to the destination. I assume the Arris cable modem has a WIFI repeator on board, this would explain the same IP range. Adding a firewall (Firewalla) will NOT help you. The firewall, you would be adding, would never see the packets from the WIFI devices.

Again, I don't have and know the capabilities of an Arris cable modem. It may be possible, but NOT with the information you have provided.

36

This is the reason why I mention Firewalla:

Firewalla once started, will start to tell each of the connected devices that it is the router and tell everyone"please send all network traffic over". This essentially will virtually divert all live traffic to Firewalla to be monitored and managed.

Professionally, this method is called arp spoofing. A 'creative way' to do a man in the middle. In our case, the 'good' man is Firewalla. And we modified a few things to make this work better at home. (This method was an inspiration from another product on the market, we take no credit inventing this)

But why does the Pi Hole tcpdump capture Chromecast multicast packets? I see what you mean that it's taking the shortest path so hence no 8.8.8.8 in the capture. Just wondering why the multicast traffic does get captured.

37

The multicast packets can be seen by any device on the LAN. mDNS/DNS-SD is a protocol suite that enables you to plug your laptop or computer into a network and instantly be able to view other people who you can chat with, find printers to print to or find files being shared. There are applications, such as ´wireshark´, tcpdump, other..., that are capable of showing the content of these packets. I believe (not sure) google home, the android application uses these packets to find the location of the chromecast on the network, so you will be able to configure the device (you never have to tell google home where the chromecast is, it finds the device by using these packets).

38

Ok so what so you think about the Firewalla?

39

Don't know the product. It looks like something to use to overcome problems with existing (inferior ?) network equipment.