Sob, could DNS be also assigned on a per VLAN basis?
How bout on LAN IP basis?
All traffic using this VLAN should go out the internet and use DNS 8.8.8.8 ??
or LanIP 192.168.2.xx shall use DNS 8.8.8.8 ??
You can give separate DNS addresses to different IP groups etc via DHCP server network option (as sob noted) or you could use NAT or something else to redirect DNS requests for specific src-addresses, although this is the messier of the options if you can use DHCP your much better doing it that way.
Much thanks SOB,
I have added 192.168.0.98/32 and assigned DNS server 8.8.8.8 to the dhcp server list.
So that part seems fairly easy.
I also added 8.8.8.8 to my DNS server list but probably not required.
/ip dns
set allow-remote-requests=yes servers=8.8.4.4,8.8.8.8,208.67.220.220
and have the following applicable firewall rules.
add action=accept chain=input comment="Allow LAN DNS queries-UDP" dst-port=53 \
in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=\
53 in-interface-list=LAN protocol=tcp
My concern is what happens to that particular dhcp servers setup entry if I also have DNS redirect in my dstnat rules??
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - TCP" dst-port=53 protocol=tcp
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - UDP" dst-port=53 protocol=udp
(should I add the following source address to the rules) !192.168.0.98
I expect that you probably don’t have other dstnat rules that should apply to traffic from 192.168.0.98, so one rule for everything from that address should be ok. And I don’t know if you meant it that way, but “accept” in dstnat is not the same as e.g. in forward, it doesn’t open anything, it stops processing in dstnat chain, i.e. saying “there will be no dstnat for this connection”.
Hmm okay, in that case I prefer the !192.168.0.98 src address entry in the existing rules.
Well no combination of rules tried has allowed this device to get thru, however funnily enough, the T5 thermostat also Honeywell, connects just fine.
It produced quite a convoluted wire shark file with connections with two main IPs, one for Https and handshakes and another for I guess more for admin and device control.
Im starting to suspect its something either than DNS but cannot figure out what.
I should add and perhaps you can comment, that when I put 192.168.0.98/32 with gateway 0f 192.168.0.1 as a DHCP network in addition to the overlapping and existing homelan, the wifi connection attempt is aborted or stopped almost right away as if this was a greater impediment to connectivity than without it. Does that make any sense???
If it’s connecting outside to some control server, then dns resolution probably went fine. You can check the packets you capture and find out what exactly happens.
If you use /32, it’s point-to-point addressing and not all devices support that. It’s not too exotic, even Windows can do it, and they are usually not seen as model system with advanced network features. But some other systems can have problems with it.
I agree SOB and continuing the discussion in the other thread Smart Devices. A different device has a similar issue, wifi not a problem but talking to home yes, and could be ICMP related?
I included some logs and sharkfile output to view. Leaving this thread nowl