How do you block the DNS of a device

[vandriver]

How do you block the dns of a single device?

Putting this in asus wireless as all my units are ac86u's?

6 x ac86us, 1 main 5 ap's, all running merlin, everything on the network cat7/8 cable where possible, iot devices on guest network, channels okay, settings on routers i think are okay, have spent years reading this forum for answers and tried and tested what worked for my own environment.

how do you block the dns of a single device? I cant find the answer anywhere. I dont know if im using the wrong search terms or what.

I have over a hundred tuya devices running through home assistant and over time have transferred them onto tuya local to try and stop disconnections and find some stability.

Now I need to block incoming, outgoing and dns connections for each device.

I've just installed Skynet and blocked the ip's of the devices but how on earth do block the dns? The devices will sit in a zombie state if I only block incoming and outgoing, apparently i need to block the dns too?

I would be very great full if someone could point me in the right direction. Thanks

 

[Justinh]

Could you use Firewall > Network Services Filter? Point the LAN IP to a black hole?

 

[vaboro]

I've just installed Skynet and blocked the ip's of the devices

Did I understand you correctly that you blocked LAN IP's of IoT devices?

The devices will sit in a zombie state if I only block incoming and outgoing, apparently i need to block the dns too?

Do you mean that blocking LAN traffic of IoT devices sends them to "zombie" state?
I personally use AdGuardHome to block DNS traffic of certain LAN clients. The regex /^.*/ does the whole job:

Spoiler: AdGuardHome custom filtering rules

AdGuardHome is used to resolve all DNS traffic on LAN and for DNS caching. Query Log is very nice.

 

[vandriver]

Did I understand you correctly that you blocked LAN IP's of IoT devices?

Do you mean that blocking LAN traffic of IoT devices sends them to "zombie" state?
I personally use AdGuardHome to block DNS traffic of certain LAN clients. The regex /^.*/ does the whole job:

Spoiler: AdGuardHome custom filtering rules

View attachment 54383

AdGuardHome is used to resolve all DNS traffic on LAN and for DNS caching. Query Log is very nice.

Its a long story but yes following advice on github I installed Skynet to block the ip's of certain IOT devices. The devices will sit in a zombie state until I block the DNS too. But ive since decided to not to go down this route since I wont be able to use the echo voice commands to control the rooms which is something the rest of the family use daily.
I think as I start to post on forums asking for help its becoming clear it may not be possible to get these devices to stay online permanently. Ive honestly spent nearly 3 years trying to get the network to run these bulbs including different manufacturers and im just not getting it lol Even a simple main router or access point reboot will almost definitely result in at least 1 device going into a zombie state/going offline and needing a power recycle to get it back online, its so frustrating. The strange thing is well is we have to switch the power of the zombie device off and count to 10 seconds (im not joking) before switching it back on. 95% of the time this gets the device back online. Anything less than 10 seconds and it wont come back online, im mean what is going on there, the 10 second bulbs lol

 

[vandriver]

Did I understand you correctly that you blocked LAN IP's of IoT devices?

Do you mean that blocking LAN traffic of IoT devices sends them to "zombie" state?
I personally use AdGuardHome to block DNS traffic of certain LAN clients. The regex /^.*/ does the whole job:

Spoiler: AdGuardHome custom filtering rules

View attachment 54383

AdGuardHome is used to resolve all DNS traffic on LAN and for DNS caching. Query Log is very nice.

Sorry, its early morning here, thanks for the advice.

 

[sfx2000]

I've just installed Skynet and blocked the ip's of the devices but how on earth do block the dns? The devices will sit in a zombie state if I only block incoming and outgoing, apparently i need to block the dns too?

You can redirect the DNS over to the Router itself with a couple of rules... tweak as needed to fit your situation

# Redirect DNS requests to go through router
iptables -t nat -A PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -i br-guest -p udp --dport 53 -j DNAT --to 192.168.1.1

Once there, you can apply your scripts to sort things out...

 

[vaboro]

Its a long story but yes following advice on github I installed Skynet to block the ip's of certain IOT devices. The devices will sit in a zombie state until I block the DNS too.

The main purpose of Skynet, imho, is to block Internet traffic (internet IP's, domains, ranges, ASN's). I presumed (but never tested yet) that if one blocks local (LAN) IP address with Skynet, all local communications with that IP will be blocked.

 

[vaboro]

You can redirect the DNS over to the Router itself with a couple of rules..

You assume that IoT devices don't allow to choose DNS server (have DNS server hardwired in the firmware), right?

 

[vaboro]

But ive since decided to not to go down this route since I wont be able to use the echo voice commands to control the rooms which is something the rest of the family use daily.

Do you mean that members of your family need access to IoT devices in the house from WAN (for example to control the rooms while they're not at home)?

 

[vandriver]

You assume that IoT devices don't allow to choose DNS server (have DNS server hardwired in the firmware), right?

Yeah I only started reading/learning about that a couple of weeks ago about some IOT devices being hard coded with DNS server. I can't confirm if any of mines do though.

 

[vandriver]

Do you mean that members of your family need access to IoT devices in the house from WAN (for example to control the rooms while they're not at home)?

They use Echo devices in each room to control the IOT devices within that room, while they are in that room. Sometimes they will use another rooms echo to control an IoT device in another room. For example they are in the kitchen and ask the kitchen echo to switch on the IoT devices in the bathroom (mostly GU10 smart bulbs) so there is light in the bathroom when they arrive at that room.
We sometimes use the IoT devices from WAN when we are not at home. Like switching in lights before we arrive home or checking NEST heating.

The smart bulbs were originally controlled via the smart life app which uses the internet connection but over time I tried to move all the bulbs and power switches over to home assistant and run them local. It hasn't worked as I still get bulbs going offline after a simple router reboot. They can be online for days before that. Is that something to do with the DNS perhaps?

The other problem with them going local was I think the echos were no longer picking them up as being online as they were blocked in skynet. This meant the IoT devices were no longer in the echo groups which broke the function the family uses daily.

All other devices like firesticks, echos door bells etc all come back online after a router or access point reboot as expected. But the bulbs and some switches just don't and I don't get it lol.

 

[RMerlin]

You can redirect the DNS over to the Router itself with a couple of rules...

Or you can use DNS Director, which does that.

 

[vaboro]

But the bulbs and some switches just don't

Don't they use zeroconf to be detected by echos?

 

[vandriver]

Don't they use zeroconf to be detected by echos?

Thanks I'll look into that too. All advice and suggestions greatly appreciated.

 

[RandomUser777]

Its a long story but yes following advice on github I installed Skynet to block the ip's of certain IOT devices. The devices will sit in a zombie state until I block the DNS too. But ive since decided to not to go down this route since I wont be able to use the echo voice commands to control the rooms which is something the rest of the family use daily.
I think as I start to post on forums asking for help its becoming clear it may not be possible to get these devices to stay online permanently. Ive honestly spent nearly 3 years trying to get the network to run these bulbs including different manufacturers and im just not getting it lol Even a simple main router or access point reboot will almost definitely result in at least 1 device going into a zombie state/going offline and needing a power recycle to get it back online, its so frustrating. The strange thing is well is we have to switch the power of the zombie device off and count to 10 seconds (im not joking) before switching it back on. 95% of the time this gets the device back online. Anything less than 10 seconds and it wont come back online, im mean what is going on there, the 10 second bulbs lol

Zigbee for bulbs & sensors. Get away from wifi.

 

[vandriver]

Zigbee for bulbs & sensors. Get away from wifi.

Thanks. I've been seeing lots of recommendations to move onto Zigbee to get away from wifi (generally at the bottom of threads where people looking for help with wifi bulbs lol)
I haven't looked into it yet because I have spent a fair amount of time and money on these tuya wifi bulbs and sensors thinking they would just work. But I will definitely look into Zigbee down the line if I feel its game over with Tuya.

My whole network has been online for 3 days now with no errors or drop out untill this morning. A wifi switch/plug disconnected from the network shorty after 6am. Recorded on router logs as a disassociation and on tuyas website as a keep alive time out. The switch automatically reconnected to the router after a few minutes as was controllable via the echos and home assistant which is great but home assistant was still logging the initial error every minute which soon builds a large text file if it went unnoticed.

At 6am we had a cordless landline phone, iphone and android phones wake up alarms go off, and 2 automation's on home assistant to switch on some lights in some downstairs room. Im guessing one of those events has took the switch out momentarily? Is that how wifi would work? I can put the downstairs lights on and off all day long and it wont effect the switch upstairs but over night the network traffic is minimum so does the sudden burst of the automatons or phone alarms cause higher than normal interference?

 

[vandriver]

Router Log:

Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:58 wlceventd: wlceventd_proc_event(494): wl0.2: Deauth_ind A0:92:08:46:91:E6, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 14 06:05:58 wlceventd: wlceventd_proc_event(511): wl0.2: Disassoc A0:92:08:46:91:E6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:09:21 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:09:21 wlceventd: wlceventd_proc_event(559): wl0.2: Assoc A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:10:59 wlceventd: wlceventd_proc_event(494): wl0.2: Deauth_ind A0:92:08:46:91:E6, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 14 06:10:59 wlceventd: wlceventd_proc_event(511): wl0.2: Disassoc A0:92:08:46:91:E6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(559): wl0.2: Assoc A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:22:29 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 5E:59:74:6D:C9:E2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:29 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 5E:59:74:6D:C9:E2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:55 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:55 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:23:25 wlceventd: wlceventd_proc_event(530): eth6: Auth F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 06:23:25 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 06:34:21 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:34:21 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 07:04:29 wlceventd: wlceventd_proc_event(530): eth6: Auth F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 07:04:29 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 07:26:30 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 07:26:30 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0



Tuyas Website:

2023-12-14 09:01:31	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:31712||UTC:1702544491||DST:1702544491	device itself
2023-12-14 08:01:30	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:31712||UTC:1702540890||DST:1702540890	device itself
2023-12-14 07:01:30	Device semaphore	Device semaphore	signal intensity:-59||Remaining memory:31712||UTC:1702537290||DST:1702537290	device itself
2023-12-14 06:14:04	Online	Online		device itself
2023-12-14 06:08:25	Offline	Offline	keepalive_timeout	device itself
2023-12-14 06:01:30	Device semaphore	Device semaphore	signal intensity:-60||Remaining memory:32688||UTC:1702533690||DST:1702533690	device itself
2023-12-14 05:01:29	Device semaphore	Device semaphore	signal intensity:-57||Remaining memory:32688||UTC:1702530089||DST:1702530089	device itself
2023-12-14 04:01:28	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:32688||UTC:1702526488||DST:1702526488	device itself
2023-12-14 03:01:28	Device semaphore	Device semaphore	signal intensity:-56||Remaining memory:32688||UTC:1702522888||DST:1702522888	device itself
2023-12-14 02:01:28	Device semaphore	Device semaphore	signal intensity:-57||Remaining memory:32688||UTC:1702519288||DST:1702519288	device itself

 

[vaboro]

Router Log:

Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:58 wlceventd: wlceventd_proc_event(494): wl0.2: Deauth_ind A0:92:08:46:91:E6, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 14 06:05:58 wlceventd: wlceventd_proc_event(511): wl0.2: Disassoc A0:92:08:46:91:E6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:09:21 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:09:21 wlceventd: wlceventd_proc_event(559): wl0.2: Assoc A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:10:59 wlceventd: wlceventd_proc_event(494): wl0.2: Deauth_ind A0:92:08:46:91:E6, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 14 06:10:59 wlceventd: wlceventd_proc_event(511): wl0.2: Disassoc A0:92:08:46:91:E6, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(530): wl0.2: Auth A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:13:39 wlceventd: wlceventd_proc_event(559): wl0.2: Assoc A0:92:08:46:91:E6, status: Successful (0), rssi:0
Dec 14 06:22:29 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 5E:59:74:6D:C9:E2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:29 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 5E:59:74:6D:C9:E2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:55 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:22:55 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:23:25 wlceventd: wlceventd_proc_event(530): eth6: Auth F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 06:23:25 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 06:34:21 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:34:21 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 07:04:29 wlceventd: wlceventd_proc_event(530): eth6: Auth F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 07:04:29 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc F4:0E:01:09:CE:6F, status: Successful (0), rssi:0
Dec 14 07:26:30 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 07:26:30 wlceventd: wlceventd_proc_event(511): eth6: Disassoc F4:0E:01:09:CE:6F, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0



Tuyas Website:

2023-12-14 09:01:31	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:31712||UTC:1702544491||DST:1702544491	device itself
2023-12-14 08:01:30	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:31712||UTC:1702540890||DST:1702540890	device itself
2023-12-14 07:01:30	Device semaphore	Device semaphore	signal intensity:-59||Remaining memory:31712||UTC:1702537290||DST:1702537290	device itself
2023-12-14 06:14:04	Online	Online		device itself
2023-12-14 06:08:25	Offline	Offline	keepalive_timeout	device itself
2023-12-14 06:01:30	Device semaphore	Device semaphore	signal intensity:-60||Remaining memory:32688||UTC:1702533690||DST:1702533690	device itself
2023-12-14 05:01:29	Device semaphore	Device semaphore	signal intensity:-57||Remaining memory:32688||UTC:1702530089||DST:1702530089	device itself
2023-12-14 04:01:28	Device semaphore	Device semaphore	signal intensity:-58||Remaining memory:32688||UTC:1702526488||DST:1702526488	device itself
2023-12-14 03:01:28	Device semaphore	Device semaphore	signal intensity:-56||Remaining memory:32688||UTC:1702522888||DST:1702522888	device itself
2023-12-14 02:01:28	Device semaphore	Device semaphore	signal intensity:-57||Remaining memory:32688||UTC:1702519288||DST:1702519288	device itself

I suppose this association/disassociation stuff originates in Asus AiMesh technology. I presume the system of nodes can't decide which of them the wifi switch/plug should connect to. I think there should be a way to manually configure which node the switch should be connected to (though I've never done it myself).

 

[sfx2000]

Going into Zigbee vs WiFi vs BLE vs Z-Wave vs Thread - this is likely a topic on it's own over in the SmartHome sub-forum...

 

[sfx2000]

Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:13 wlceventd: wlceventd_proc_event(511): eth6: Disassoc 56:97:35:4E:AE:74, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Dec 14 06:05:58 wlceventd: wlceventd_proc_event(494): wl0.2: Deauth_ind A0:92:08:46:91:E6, status: 0, reason: Disassociated due to inactivity (4), rssi:0

This isn't much to worry about - Debug is turned up fairly high on the wifi drivers...

So while it looks like something bad is happening, it really isn't - these are devices that are working properly...