I have set up several VLANs and have restricted LuCI and ssh to listen only on one "main" interface instead of all of them. I then selectively added some firewall rules to allow a few hosts to administer my router across VLANs/zones.
However, this now presents an inconvenience: the my-openwrt-router.lan seems to somehow resolve differently on each VLAN!
So the router listens on 192.168.1.1 ("infrastructure" VLAN 100) and, because I've set up a firewall rule to allow it, my laptop can technically connect to the router from 192.168.2.42 ("normal users" VLAN 200). But the problem is, I can only connect if do so via raw IP (ssh root@192.168.1.1). If I try to connect via hostname (ssh root@my-openwrt-router.lan) the hostname gets resolved not to the router's "main" 192.168.1.1 address but rather the address of its "extra" 192.168.2.1 interface instead. And since it's not listening on that interface, connecting via hostname fails.
So it seems that dnsmasq is running separate resolvers on each interface, or at least giving different answers depending on which interface a query comes in on.
Is there any way I can get a little more control over the per-interface dnsmasq configuration? Can I somehow tell it to call itself vlan200-router.lan (instead of its actual my-openwrt-router hostname) on the VLAN 200 interface and let the main hostname point to the "main" (VLAN 100) IP address?
Just found the localise_queries option (even available via LuCI under "DHCP and DNS > Advanced Settings") which seems to sort of solve this.
Instead of just the "wrong" IP address of the router's VLAN interface (well not really, but not the one I want) it gives me all the router's IP addresses of all the interfaces. Which isn't great but my ssh and https clients seem to pick the right one to use in the end.
So maybe there's still a cleaner way to do this, but I found a partial solution anyway!
UPDATE: a few more details as I figure them out. Via ps w | grep dns I found dnsmasq running as:
And there is indeed a /tmp/hosts/dhc.cfgNNNNN file in that directory which includes the names of not just other (i.e. DHCP client) hosts but also many entries for the router itself. I don't know what creates that /tmp/hosts file or what other uses it has, but I'm reasonably certain that modifying it manually is not a good solution here.
UPDATE2: it looks like that hosts file gets populated by the /etc/init.d/dnsmasq script, which again seems like a bad idea to edit. I do not see any way to set a separate "hostname" on an interface-by-interface basis. (And haven't tracked down exactly which part of the init.d script fills in the router's own entries yet. Most likely through its call to dhcp_this_host_add from within dhcp_add)
I can at least give you a push in the right direction since you seem a bit lost i the file system of linux.
Go to: \etc\config\dhcp
But as far I know you can only have one interface for the DNS resolv so you need to decide if that is the admin interface or not. You will have pros and cons when doing it like this.
But I don’t think dnsmasq handles multi VLAN environment well in this kind of setup profile.
This was surprising, so I searched the forums and at least found:
actually via this thread:
There's still not a lot of details in those, but I'm guessing that the race condition is between the startup of uhttpd vs. the network interface(s) configured for it? I.e. the LuCI service configured to listen on 192.168.1.1 comes up before the interface with that IP address → problems? And same for the ssh daemon too?
I forget where I found the instructions for limiting the listening interfaces, but ideally that warning might be more prominent if it's in the wiki or whatnot. Otherwise the "obvious" thing to do is listen only on the more trusted interfaces to start with, rather than listening on all interfaces and then hoping the firewall ends up remaining reliably configured to block some/all traffic) is to listen.
BTW, and again I'm always interested in more perspectives ideas, but personally I ended up "solving" this more simply: by editing /etc/hosts on the couple machines that can manage the router from the less-trusted VLAN.
If I end up backing out my "listen on only one interface" change that would also be a solution.
Other things I considered:
leaving the localise_queries option off — but that seemed messy/leaky to always be sharing all the possible IP addresses of the router. (And it wasn't clear to me that all clients would prefer the first 192.168.1.1 record over the 192.168.2.1 record that ostensibly matches its own netmask better.)
accessing the router via a separate hostname record for my-openwrt-router-admin-ip.lan just hardcoded to the right IP address
again, maybe the real recommended solution is to not to listen only on one VLAN in the first place, and the problem goes away again [until some rogue IoT device pounces on an accidentally bad firewall setting :-P]