Dnsmasq, DNS vs DHCP interface listen

I had something weird happen and am wondering whether there is a more proper way to do it.

I have four internal VLAN's, one a guest, and of course the external ISP interface. I noticed that port 53 was open on all of them (though the firewall was blocking the outside), and decided I wanted it closed on the guest interface. On that interface I provide via DHCP options external DNS, I do not want the guests seeing internal names (though it is a bit of a stretch that someone (a) could figure out how, and (b) it would even matter).

So I changed from all, to listing the interfaces for (I thought) DNS listeners.

What happened was I could no longer connect to the guest network. I watched under the wireless display and could see something trying, getting through authentication, getting an IP... then giving up. Though I could see it assigned an IP in the "Associated stations" it was not pingable.

In this state, netstat shows port 67 open on 0.0.0.0, but 53 only on each interface I listed. So it looks like it did the right thing relative to DHCP vs DNS.

But without the "list interface" for the guest in the config file, I cannot fully associate. Note in doing the testing I did not change the interface configuration for dhcp further down in the file.

During the failure time the log looks like this:

Thu Aug 22 15:13:06 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: authenticated
Thu Aug 22 15:13:06 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: associated (aid 1)
Thu Aug 22 15:13:06 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:13:06 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c WPA: pairwise key handshake completed (RSN)
Thu Aug 22 15:13:42 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:13:45 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: authenticated
Thu Aug 22 15:13:45 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: associated (aid 1)
Thu Aug 22 15:13:45 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:13:45 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c WPA: pairwise key handshake completed (RSN)
Thu Aug 22 15:14:21 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:14:24 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: authenticated
Thu Aug 22 15:14:24 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: associated (aid 1)
Thu Aug 22 15:14:24 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:14:24 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c WPA: pairwise key handshake completed (RSN)
Thu Aug 22 15:15:00 2019 daemon.notice hostapd: wlan1-1: AP-STA-DISCONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:15:03 2019 daemon.info hostapd: wlan1: STA b4:f1:da:b2:67:9c IEEE 802.11: authenticated
Thu Aug 22 15:15:03 2019 daemon.info hostapd: wlan1: STA b4:f1:da:b2:67:9c IEEE 802.11: associated (aid 3)
Thu Aug 22 15:15:03 2019 daemon.notice hostapd: wlan1: AP-STA-CONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:15:03 2019 daemon.info hostapd: wlan1: STA b4:f1:da:b2:67:9c WPA: pairwise key handshake completed (RSN)

The working case:

Thu Aug 22 15:17:04 2019 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:17:04 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: authenticated
Thu Aug 22 15:17:04 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c IEEE 802.11: associated (aid 1)
Thu Aug 22 15:17:04 2019 daemon.notice hostapd: wlan1-1: AP-STA-CONNECTED b4:f1:da:b2:67:9c
Thu Aug 22 15:17:04 2019 daemon.info hostapd: wlan1-1: STA b4:f1:da:b2:67:9c WPA: pairwise key handshake completed (RSN)
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPDISCOVER(br-Guest) b4:f1:da:b2:67:9c
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPOFFER(br-Guest) 192.168.134.210 b4:f1:da:b2:67:9c
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPDISCOVER(br-Guest) b4:f1:da:b2:67:9c
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPOFFER(br-Guest) 192.168.134.210 b4:f1:da:b2:67:9c
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPREQUEST(br-Guest) 192.168.134.210 b4:f1:da:b2:67:9c
Thu Aug 22 15:17:08 2019 daemon.info dnsmasq-dhcp[7673]: DHCPACK(br-Guest) 192.168.134.210 b4:f1:da:b2:67:9c

It's like I need to open the DNS port for it to properly do the DHCP handshake (at least to completion).

If this was a separate DHCP and DNS server that would not be the case (right?).

Is this a side effect of DNSMASQ, that it conflates the two ports in some fashion?

I realize I can use iptables to restrict the guest interface's access to DNS. At least I think I can (have not tried yet, I guess it's possible that would interfere also). This is more a curiosity question than a real problem. But... why is it doing this? Am I missing something obvious? Thanks.

Linwood

I've done something similar:

  • Block input to guest by default
  • Allow DHCP-requests
  • Adding public DNS servers using DHCP Option No. 6
#allow DHCP requests
config rule                                 
        option target 'ACCEPT'                      
        option proto 'udp'             
        option dest_port '67'
        option name 'Allow-DHCP'
        option family 'ipv4'
        option src 'untrusted'
        option src_port '68'

1 Like

Thanks, @lleachii something like that can work, I was surprised there was no way to separately specify listen ports for dnsmasq for dns and dhcp separately. But apparently not, at least not that I can see.

I was under impression that's achievable with the dnsmasq tagging. Have you looked into this?

2 Likes

dnsmasq (and its uci integration) has all the provisions to start multiple, non-shared, instances from the same config, each isolated to their zone.

3 Likes