Hard Coded DNS & Man in the middle redirect

CAExempt · Sep 18, 2019, 5:41 AM

Apple TV's appear (or Youtube & Netflix Apps) to have hard-coded DNS evident by the state table below
(We dont use Google DNS at all on the network)

I tried redirecting DNS like the below as mentioned here however this stops both YouTube & Netflix from working all together, it just hangs and fails after 30 seconds saying timeout.

How could I go about preforming a man in the middle style redirect to force google DNS back to pfsense and out through the DNS listed in System -> General Setup -> DNS Server Settings, this causes issues when using a VPN and trying to watch Netflix etc.

If you reply on how you manage this on your network, please post screenshots so I can understand how to do it, thank you

login-to-view
login-to-view
login-to-view

Konstanti · Sep 18, 2019, 7:21 AM

@CAExempt
Hi
The Netflix and Youtube apps for Apple TV to use the DNS server specified in network settings Apple TV (192.168.1.38)
For example , for my Apple TV DNS server 192.168.1.230
And that's what gives the DNS server when i run Youtube

09:59:47.862676 IP 192.168.1.38.54578 > 192.168.1.230.domain: 47275+ A? www.youtube.com. (33)
09:59:47.931997 IP 192.168.1.230.domain > 192.168.1.38.54578: 47275 11/13/1 CNAME youtube-ui.l.google.com., A 216.58.209.238, A 216.58.215.46, A 216.58.213.174, A 172.217.19.238, A 216.58.198.206, A 216.58.206.238, A 216.58.213.142, A 172.217.22.142, A 172.217.18.206, A 216.58.204.142 (502)
09:59:48.490029 IP 192.168.1.38.52980 > 192.168.1.230.domain: 45641+ A? s.ytimg.com. (29)
09:59:48.624080 IP 192.168.1.230.domain > 192.168.1.38.52980: 45641 2/13/12 CNAME ytstatic.l.google.coM., A 216.58.201.238 (504)
09:59:50.010308 IP 192.168.1.38.56054 > 192.168.1.230.domain: 59689+ A? www.gstatic.com. (33)
09:59:50.077492 IP 192.168.1.230.domain > 192.168.1.38.56054: 59689 1/13/13 A 216.58.204.131 (496)

or when i run Netflix

10:08:35.651717 IP 192.168.1.38.61087 > 192.168.1.230.domain: 11383+ A? www.netflix.com. (33)
10:08:35.682073 IP 192.168.1.38.64193 > 192.168.1.230.domain: 52164+ A? settings.crashlytics.com. (42)
10:08:35.684445 IP 192.168.1.38.51477 > 192.168.1.230.domain: 59893+ A? ichnaea-web.netflix.com. (41)
10:08:35.739318 IP 192.168.1.230.domain > 192.168.1.38.64193: 52164 8/13/5 A 54.225.160.80, A 23.23.216.87, A 54.225.236.110, A 50.19.83.69, A 50.19.234.168, A 54.243.48.217, A 23.23.167.107, A 50.17.183.0 (498)
10:08:35.840627 IP 192.168.1.230.domain > 192.168.1.38.61087: 11383 10/13/3 CNAME www.geo.netflix.coM., CNAME www.eu-west-1.prodaa.netflix.coM., A 52.208.135.54, A 52.209.79.186, A 52.17.227.174, A 54.171.187.60, A 34.252.179.162, A 52.17.219.77, A 54.77.143.196, A 52.18.15.9 (505)
10:08:35.852853 IP 192.168.1.230.domain > 192.168.1.38.51477: 59893 10/13/1 CNAME ichnaea-web.geo.netflix.coM., CNAME ichnaea-web.eu-west-1.prodaa.netflix.coM., A 52.18.176.52, A 52.213.199.242, A 52.214.59.143, A 52.49.53.175, A 34.251.174.245, A 54.171.216.92, A 52.17.69.132, A 34.250.195.245 (505)
10:08:35.995727 IP 192.168.1.38.50454 > 192.168.1.230.domain: 60384+ A? e.crashlytics.com. (35)

But the Google Mini and Chromecast use DNS server 8.8.8.8

00:00:00.000000 e4:f0:42:0f:51:34 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.40.35393 > 8.8.8.8.53: 59176+ A? www.google.com. (32)
 00:00:00.114074 00:08:a2:0a:ff:73 > e4:f0:42:0f:51:34, ethertype IPv4 (0x0800), length 90: 8.8.8.8.53 > 192.168.1.40.35393: 59176 1/0/0 A 216.58.211.36 (48)
 00:00:00.004506 e4:f0:42:0f:51:34 > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.40.35393 > 8.8.8.8.53: 60456+ AAAA? www.google.com. (32)
 00:00:00.086354 00:08:a2:0a:ff:73 > e4:f0:42:0f:51:34, ethertype IPv4 (0x0800), length 102: 8.8.8.8.53 > 192.168.1.40.35393: 60456 1/0/0 AAAA 2a00:1450:4003:809::2004 (60)
 00:00:25.596372 54:60:09:e9:fa:8a > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.39.40606 > 8.8.8.8.53: 61232+ A? www.google.com. (32)
 00:00:00.000172 54:60:09:e9:fa:8a > 00:08:a2:0a:ff:73, ethertype IPv4 (0x0800), length 74: 192.168.1.39.40606 > 8.8.8.8.53: 62256+ AAAA? www.google.com. (32)
 00:00:00.107032 00:08:a2:0a:ff:73 > 54:60:09:e9:fa:8a, ethertype IPv4 (0x0800), length 102: 8.8.8.8.53 > 192.168.1.39.40606: 62256 1/0/0 AAAA 2a00:1450:4003:809::2004 (60)
 00:00:00.016591 00:08:a2:0a:ff:73 > 54:60:09:e9:fa:8a, ethertype IPv4 (0x0800), length 90: 8.8.8.8.53 > 192.168.1.39.40606: 61232 1/0/0 A 216.58.211.36 (48)

Here is how I have done to redirect UDP DNS request from Google Chromecast (192.168.1.35) to 8.8.8.8

login-to-view

This rule is created automatically
login-to-view

JeGr · Sep 18, 2019, 7:12 AM

The rule in your picture is wrong, it shouldn't be IoT_net but _address. Also you didn't show any Port Forward / Outbound NAT settings. Without them you can't redirect the traffic to localhost. If you don't have any, then you simply block DNS so that's why your DNS resolving won't work anymore.

CAExempt · Sep 18, 2019, 7:26 AM

@JeGr Here is the Outbound NAT, sorry for the blank areas, I don't like to give out publicly which VPN provider I use
So, what should I do here to correct the issue?

login-to-view

&& Here is Port fowarding

login-to-view

Gertjan · Sep 18, 2019, 7:34 AM

@JeGr said in Hard Coded DNS & Man in the middle redirect:

Without them you can't redirect the traffic to localhost.

Here is that NAT rule :

login-to-view

I just tried it : I informed my iPhone that its DNS is static : 8.8.8.8
It will get redirected to the pfSense Resolver.

As proposed by Redirecting all DNS Requests to pfSense ( and related Blocking DNS queries to external resolvers )

Btw : My Apple devices, and TV's, do not use a 'hard coded' DNS. Devices that do so could be problematic, because there are ISP's out there that do the same thing : redirecting your DNS requests, no matter where you - your devices - want to send them.

Not related, but take note : my iPhone, Apple TV, TV prefers IPv6 ..... Take note : you can't "NAT" IPv6,- pfSense ( ? ) won't accept '::1' as the IPv6 localhost or any IPv6 as a redirect IP.

CAExempt · Sep 18, 2019, 7:40 AM

@Gertjan Right this is the same as the current one I have going, and it seems to work ok in redirecting, it's more once the redirect is done as seen with the state table screen grab below, it appears to break down and no longer resolves anything on netflix, it will just hang indefiantly.

login-to-view

CAExempt · Sep 18, 2019, 10:16 AM

@Konstanti DNS in my apple TV is pfsense for the IoT Network @ 192.168.14.1
So you're saying this should work?? The Alias has two apple TV IPs in it.

login-to-view

johnpoz · Sep 18, 2019, 10:22 AM

Your state table is correct.. It shows client tried to go to 8.8.8.8 and ended up on 127.0.0.1

What do you think the state table should show?

CAExempt · Sep 18, 2019, 11:28 AM

@johnpoz Exactly that, however as mentioned both Netflix and Youtube hang and timeout after a while. I've noticed then under "Block External DNS Servers" rule, the traffic value goes up.

What could that be?

Edit, I just want to confirm on the port forward redirect rule "NAT reflection" should be listed as "Disable" correct?

login-to-view

&& The rules should be in this order? Do i NEED the allow to pfsense & block outside DNS?
Keep in mind this entire network runs on a VPN, so trying to avoid DNS leaks too.

login-to-view

Gertjan · Sep 18, 2019, 11:31 AM

login-to-view

Red arrow above : be careful : do not limit DNS traffic to UDP only. DNS over TCP is a reality.
Bellow : me thinking out loud here : redirecting to localhost or 127.0.0.1 is what should be done.
Your redirect to "192.168.14.1" (the IO Net ?) means that the traffic comes in again into the "IO net" interface, will be redirected again, etc etc - a loop ? Also : is unbound listening on "192.168.14.1" ? It listens to 127.0.0.1 for sure.

CAExempt · Sep 18, 2019, 11:35 AM

@Gertjan mmm you have a point, it would be a loop over and over again.
Essentially, the DNS I need this to go via is 104.223.91.194 or it's secondary of 104.223.91.210.

Under DNS Resolver, Network Interfaces is listed as ALL, therefore unbound would resolve from 192.168.14.1. I have attempted to only allow a resolver from localhost, it's a 50/50 if a website will resolve when selected only on localhost.