Reply
Established Member
Posts: 1,278
Registered: ‎07-17-2013
Kudos: 857
Solutions: 85
Contributions: 1

BUG: dnsmasq behavior on UAPs

[ Edited ]

Starting i don't know exactly when, UniFi APs started redirecting DNS requests, on any guest enabled SSID, to a local running dnsmasq instance. And that happens only when 'Enable Guest Portal' is checked. If guest portal is disabled, if you have enabled guest network for devices isolation only, for example, the DNS interception do not occur.

 

I got that, take care of DNS resolution to non-authenticated users, avoiding the admin having to remember to whitelist the internal IP address on the 'pre-auth rules', if that's the case. If the DNS is an internal IP, and whitelist is not made, no resolution would occur and things would not work as expected. Believe me, i got that, and no problem to me. This whole idea seems to be replacing the old idea on that hardcoded UDP/53 allow rule on past firmwares. MUCH better approach, indeed.

 

Things is that even after the user is authenticated, DNS requests are still being captured to the local dnsmasq instance, despite ebtables rules existing to, apparently, do that only for non-authenticated users. It's not working as expected, if the idea is to redirect only non-authenticated users. It's actually intercepting DNS requests from *ALL* users, authenticated and non-authenticated, and that's a nightmare to me, as it's really taking out my ability to specify different DNSs to different VLANs, via DHCP server for example.

 

Evidences ...

- AP with latest beta (4.0.38 as now) firmware, SSID with guest network enabled, guest portal enabled

- device with manual IP configuration, pointing to Google DNS, 8.8.8.8

 

- tcpdump on the ath0 (wifi) interface of the UAP

 

15:57:38.833338 IP 172.16.0.88.64676 > 8.8.8.8.53: 44503+ A? connectivitycheck.gstatic.com. (47)
15:57:38.834878 IP 8.8.8.8.53 > 172.16.0.88.64676: 44503 1/0/0 A 216.58.202.131 (63)
15:57:38.835217 IP 172.16.0.88.38391 > 8.8.8.8.53: 40970+ A? www.google.com. (32)
15:57:38.836644 IP 8.8.8.8.53 > 172.16.0.88.38391: 40970 1/0/0 A 172.217.29.4 (48)
15:57:38.945980 IP 172.16.0.88.60555 > 8.8.8.8.53: 64111+ A? clients3.google.com. (37)
15:57:38.947047 IP 8.8.8.8.53 > 172.16.0.88.60555: 64111 2/0/0 CNAME clients.l.google.com., A 172.217.30.46 (87)
15:57:38.958472 IP 172.16.0.88.62941 > 8.8.8.8.53: 50711+ A? mtalk.google.com. (34)
15:57:38.960621 IP 8.8.8.8.53 > 172.16.0.88.62941: 50711 2/0/0 CNAME mobile-gtalk.l.google.com., A 64.233.190.188 (89)
15:57:39.141735 IP 172.16.0.88.43981 > 8.8.8.8.53: 47023+ A? g.whatsapp.net. (32)
15:57:39.179927 IP 8.8.8.8.53 > 172.16.0.88.43981: 47023 2/0/0 CNAME chat.cdn.whatsapp.net., A 157.240.12.54 (71)

 

- tcpdump on the eth0 (external) interface of the UAP

 

UAP-Outdoor-BZ.v4.0.38# tcpdump -n -i eth0 port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:55:30.070420 IP 172.16.0.109.43942 > 172.16.0.1.53: 60765+ A? ssl.google-analytics.com. (42)
15:55:30.102145 IP 172.16.0.1.53 > 172.16.0.109.43942: 60765 2/0/0 CNAME ssl-google-analytics.l.google.com., A 172.217.30.104 (102)
15:55:30.685170 IP 172.16.0.109.27724 > 172.16.0.1.53: 59059+ A? api.accuweather.com. (37)
15:55:30.715673 IP 172.16.0.1.53 > 172.16.0.109.27724: 59059 3/0/0 CNAME api.accuweather.com.edgekey.net., CNAME e10414.g.akamaiedge.net., A 23.36.77.175 (132)

 

- as expected, i'm seeing my device (172.16.0.88) sending DNS requests to the configured DNS server (8.8.8.8). On the external (eth0) interface, i'm seeing the own AP IP address (172.16.0.109) sending DNS requests to the AP system DNS server (172.16.0.1). Local interception of DNS requests, for unauthorized devices, on a guest enabled SSID and with guest portal enabled, is working as expected.

 

PROBLEM is: even after authenticating on the Guest Portal, DNS interception keeps happening which, i really believe, is not the intended thing to be happening for authenticated devices:

 

- evidences:

- from Events: (device was authorized)

Captura de Tela 2019-05-15 às 16.03.13.png

 

- tcpdump on the ath0 (wifi) interface of the UAP

16:01:03.430744 IP 172.16.0.88.45092 > 8.8.8.8.53: 20977+ AAAA? www.ui.com. (28)
16:01:03.486765 IP 8.8.8.8.53 > 172.16.0.88.45092: 20977 0/1/0 (115)

- tcpdump on the eth0 (external) interface of the UAP

16:01:03.432430 IP 172.16.0.109.38326 > 172.16.0.1.53: 13547+ AAAA? www.ui.com. (28)
16:01:03.485289 IP 172.16.0.1.53 > 172.16.0.109.38326: 13547 0/1/0 (115)

EXPECT: seeing my device (172.16.0.88) sending DNS requests to the configured DNS server (8.8.8.8) going 'out' on eth0 interface, which is *NOT* happening, despite the fact i'm clearly seeing those requests on the internal (ath0) interface.

 

 

ebtables rules (which i'm not an expert) seems to check for 0x500000 mark (i'm supposed it's the authenticated user mark) and CONTINUE instead of redirect, but that's clearly not working as expected as shown:

 

allowing the DNS i'd like devices to use on pre-auth access rules, for example, is useless, as those access will be enforced by GUESTIN_ALLOWED_IPSET, on the GUESTIN chain, and that rule is located *AFTER* the DNS interception rule, which means DNS traffic is intercepted no matter any pre-auth rule for those IP addresses (of the DNS servers).

 

UAP-Outdoor-BZ.v4.0.38# ebtables -t nat -L
Bridge table: nat

Bridge chain: GUESTIN, entries: 16, policy: DROP
[ .... ]
-p IPv4 --ip-proto udp --ip-dport 53 -j GUEST_DNS
-p IPv4 --ip-proto tcp --ip-dport 53 -j GUEST_DNS
-p IPv4 -j GUESTIN_ALLOWED_IPSET Bridge chain: GUEST_DNS, entries: 2, policy: DROP -p IPv4 --ip-proto udp --ip-dport 53 -j REDIRECT_DNS -p IPv4 --ip-proto tcp --ip-dport 53 -j REDIRECT_DNS Bridge chain: REDIRECT_DNS, entries: 2, policy: ACCEPT -j mark --mark-or 0x500000 --mark-target CONTINUE -j redirect

 

 

Despite users are always having DNS resolution, the way it's working completly takes our ability to specify different DNS servers for different networks, based on DHCP decisions. Any connected user is having DNS requests intercepted, and being resolved by the UAP system DNS resolver.

 

@UBNT-teunisyou have helped me with another UAP dnsmasq problem, that is already fixed, but i'm really sure what's happening is not the expected one. Would love some attention on this Man Happy

 

and PLEASE, give us the option to *COMPLETLY* disable this whole thing of DNS interception and let my decision, on which DNS server to be used, to be *ALWAYS* respected. While i see this can help non-advanced users and unifi admins, this can be a nightmware for advanced setups. Give us the option to completly disable this instead of simply hardcoding this kind of rule.

 

Solutti Tecnologia Ltda - Goiânia/Goiás/Brazil
www.solutti.com.br / www.wifiquefunciona.com.br
Ubiquiti Enterprise Wireless Admin (UEWA) certified
did my answer helped you ? if yes, i would love your kudos on it Man Happy
Senior Member
Posts: 2,738
Registered: ‎04-21-2015
Kudos: 404
Solutions: 108

Re: BUG: dnsmasq behavior on UAPs

Mate l will give you "kudo" just for such a detail report!
Thanks,
Myky
CWNA
--------------------------------------------------------------------------------------------------------------------------------------------------
Don`t blame the device as it`s always doing what you have asked it to do, this is not always the same as what you want.
Established Member
Posts: 1,278
Registered: ‎07-17-2013
Kudos: 857
Solutions: 85
Contributions: 1

Re: BUG: dnsmasq behavior on UAPs


@myky wrote:
Mate l will give you "kudo" just for such a detail report!

You have no idea the nightmare i had because of this, until i got to realize that Man Happy Mad5

Solutti Tecnologia Ltda - Goiânia/Goiás/Brazil
www.solutti.com.br / www.wifiquefunciona.com.br
Ubiquiti Enterprise Wireless Admin (UEWA) certified
did my answer helped you ? if yes, i would love your kudos on it Man Happy
Highlighted
Senior Member
Posts: 2,738
Registered: ‎04-21-2015
Kudos: 404
Solutions: 108

Re: BUG: dnsmasq behavior on UAPs

I can imagine especially if you are into something
Thanks,
Myky
CWNA
--------------------------------------------------------------------------------------------------------------------------------------------------
Don`t blame the device as it`s always doing what you have asked it to do, this is not always the same as what you want.
Established Member
Posts: 1,278
Registered: ‎07-17-2013
Kudos: 857
Solutions: 85
Contributions: 1

Re: BUG: dnsmasq behavior on UAPs

@UBNT-MikeD  would love 2 minutes of your attention on this "DNSgate". Thanks !!

Solutti Tecnologia Ltda - Goiânia/Goiás/Brazil
www.solutti.com.br / www.wifiquefunciona.com.br
Ubiquiti Enterprise Wireless Admin (UEWA) certified
did my answer helped you ? if yes, i would love your kudos on it Man Happy
Ubiquiti Employee
Posts: 101
Registered: ‎06-27-2016
Kudos: 75
Solutions: 5

Re: BUG: dnsmasq behavior on UAPs

This is getting into territory I'm not deeply familiar with - however, I understood it that guest networks were intended to not have access to LAN - only to WAN.   Kind of a "bypass local network" thing.  If so, it's working as expected.

I think however this is going to be investigated further to make more flexible.

Thanks for the excellent report!

Established Member
Posts: 1,278
Registered: ‎07-17-2013
Kudos: 857
Solutions: 85
Contributions: 1

Re: BUG: dnsmasq behavior on UAPs


@UBNT-teunis wrote:

 .... I understood it that guest networks were intended to not have access to LAN - only to WAN.   Kind of a "bypass local network" thing.  If so, it's working as expected.


I would LOVE Ubiquiti team STOP making this kind of assumption. The network should work the way the network admin want it to work, not the way Ubiquiti want it, specially on hardcoded and undocumented configs like these one Smiley Sad I would expect this kind of thinking, "it works this way, and that's the only way" on cheap US$ 20 wireless routers, not on enterprise Access Points. Forcing this kind of idea is not compatible with enterprise grade products, which UniFi actually is. This software decisions, however, if this was intentionally done, is terrible and not compatible with the whole 'enterprise product' idea.

 

Guest networks have configurable access lists, that is the only thing that MUST/HAVE TO be enforced, not some hidden and hardcoded 'do not have access to LAN' thing.

 

I'm pretty sure this is a bug and this is *NOT* working as intended, i really can't believe/accept that this was intentionally made.

 

Anyway, once again, thanks for your attention @UBNT-teunis and sorry for letting the steam off on a reply to you Man Happy

Solutti Tecnologia Ltda - Goiânia/Goiás/Brazil
www.solutti.com.br / www.wifiquefunciona.com.br
Ubiquiti Enterprise Wireless Admin (UEWA) certified
did my answer helped you ? if yes, i would love your kudos on it Man Happy
Ubiquiti Employee
Posts: 101
Registered: ‎06-27-2016
Kudos: 75
Solutions: 5

Re: BUG: dnsmasq behavior on UAPs

No worries.

I think this is going to get some changes soon re said rant.

Mind, it's kind of a "boxed solution" to a whole pile of things - however splitting out the features into different options is coming.

 

expect more as per current hotspot 2 technologies too, I think, as a different approach to the same problem.

Reply