I have these settings for scanning for connected devices in the NetAlertX addon:
A. 192.168.0.1/24 --vlan=1
B. 192.168.10.1/24–vlan=10
C. 192.168.20.1/24 --vlan=20
A. is my internal lan, it finds all 25 devices there.
B. is my IOT vlan that has about 85 devices, it finds nothing there
C. is my guest vlan, it is finding the devices that are here.
What gives? Any ideas?
I am a bit concerned that there are devices in a guest VLAN because, ideally, you want your guest network to be isolated from your internal networks and just give them a straight shot to the Internet. My guest network does that.
I have a similar setup. Guest is VLAN 254. IoT is VLAN 253 and that includes wired ports where needed and a special Wireless SSID attached to that VLAN. I have a wired data VLAN 249 that my TVs are on and a wireless data VLAN 252 for a very few devices on my data network that cannot be wired, specifically a NVDIA Shield TV I use in my backyard when the weather is nice. My QNAP and Synology servers are on my VLAN 250, along with my printers, and all have static IP Addresses.
Now, for the NVDIA devices and Android TV devices I do have a static IP Addres or DHCP Reservation on those devices so they are the same IP Address every time. I think this is what you might have to do on that internal VLAN if your HA sits on your IoT network.
I suspect that your HA sits on the network and just listens for broadcasts from devices that have MAC addresses with OIDs that it knows. Don’t know how deep you know about computer networks but a device has a MAC address burned into each network interface that is a 12-digit hexadecimal number. It typically looks like 0123.4567.89ab or 01:23:45:67:89:ab. The first six characters are assigned by the Internet regulating body and that is your OUI.
Broadcasts are usually something looking for the MAC address of an IP Address on its same network and they are set to a special MAC Address of FF:FF:FF:FF:FF:FF. Broadcasts cannot traverse Layer-3 interfaces. Your VLANs 192.168.0.1/24, 192.168.10.1/24 and 192.168.20.1/24 IP Addresses are Layer-3 and therefore, those broadcasts will not go across those interface. So that is why you see 25 devices on 192.168.1.0/24 and 85 devices on 192.168.10.0/24.
I would suggest if you can, either move those devices on the same VLAN as your HA or use static IP Addresses if the integration can poll the device based on IP Address.
Then, I make my network even more complicated by puting an Access Control List on my IoT network VLAN Interface (VLAN 253) that specifically limits what HA can talk to on my other networks with permit statements for IP Address an tcp or udp port, deny statements after that for the RFC1918 networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), then a permit any any to allow Internet access.
Thank you @kahilzinger , to give you a little clearer picture, my HA is in the internal vlan and I have mDNS reflection across all three, along with Firewall rules such that only specific devices on the internal vlan can initiate connections with the iot vlan devices, and the iot devices cannot initiate any connections to the other vlans either. The iot vlan is also blocked from the internet and that is only removed temporarily once every three months or so for firmware updates. The firewall rules allowing connectons with the iot vlan from the internal vlan also includes not only the ha IP but also the 172.30.32.2 that NetAlertX is evidently using through HA.
With regards to the guest network, which is mainly just for guests, it has one device, my employers laptop I use for very high security IT work. It is there so it has no access to nor gets anywhere near any of my personal stuff. That is typically the only device on that vlan unless guests come over. Also, the guest vlan only has access to the printers and Chromecast in the house.
I know the mDNS reflection is working because the Chromecasts which are on the internal vlan, were still not accessable to the guest vlan, even after the firewall rules were put into place - and were finally only reachable when the mDNS reflection was turned on.
There is some kind of a hiccup with the way the NetAlertX in the internal vlan is unable to see the iot vlan.
Now that you have a clearer picture - do you have any ideas?
If you go with static IPs or DHCP reservations, you will not have to use mDNS and you can make your access lists more tailored to the IPs those devices have and will always have.
It really depends on the integration. If it does not connect by IP but by MAC address, they will have to be on the same network.
Yes, I will ask - everything has a static IP
I have posted it as a bug here, as NetAlertX is using ARPSCAN and I have from a command line on the HA host run an ARP-SCAN command and it shows every single device on that VLAN, so it is not a networking issue but probably configuration or a bug within NetAlertX…
Hi @KruseLuds
The container of NetAlertX (not the HA container!) needs to have access to the scanned networks.
Just a note, ping and ARPSCAN use different protocols so even if you can ping devices it doesn’t mean arpscan can detect them.
You can test accessibility of teh networks by running arp-scan inside of the NAX container, e.g.:
sudo arp-scan 10.20.0.0/24 --interface=ens33 --vlan=30
sudo arp-scan 10.30.0.0/24 --interface=ens33 --vlan=30
…etc.
If the above doesn’t work you need to use a different discoverability approach. These are described in this doc:
Please read the above documentation to explore alternative solutions for your setup. Happy to provided more guidance.
For more info on SUBNETS and possible accessibility scenarios, check this article as well: Subnets - NetAlertX Docs
Thank you for yuour help, I will investigate this and get b ack to you with results. I just had a knee replacement and am making funeral arrangements for my mother at the same time, so there will be a slight delay as i’ve got alot on my plate right now (work on HA is my therapy lol).
Figured it out, I had to go into the NetAlertX container using the advanced command line add-in (“Advanced SSH & Web Terminal”) with protection mode temporarily turned OFF. To find which container, issue this command:
docker ps
You should see something like this:
CONTAINER ID IMAGE NAMES
abc123def456 ghcr.io/netalertx/netalertx:latest addon_a1b2c3d4_netalertx
So then to enter that copntainer, issued this commend:
docker exec -it addon_a1b2c3d4_netalertx /bin/sh
…and then issued commands to get the correct interface:
ip link show
which showed a huge nightmare list of interfaces -
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:7e:77:2c brd ff:ff:ff:ff:ff:ff
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether da:70:0c:1b:68:4d brd ff:ff:ff:ff:ff:ff
4: home assistant OS: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
link/ether 0a:2e:50:37:c6:75 brd ff:ff:ff:ff:ff:ff
6: veth17d3a62@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether e2:f9:fc:7f:05:93 brd ff:ff:ff:ff:ff:ff link-netnsid 1
7: veth1428011@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
link/ether 4a:a7:98:a1:b1:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 1
8: veth818e4df@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether d2:3e:b6:f9:91:0d brd ff:ff:ff:ff:ff:ff link-netnsid 2
9: vethe0abb38@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether ba:bf:ad:a0:48:24 brd ff:ff:ff:ff:ff:ff link-netnsid 3
11: vethcab7520@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 3e:50:8f:86:db:6a brd ff:ff:ff:ff:ff:ff link-netnsid 5
12: vetha41ee63@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether ce:d9:97:18:66:85 brd ff:ff:ff:ff:ff:ff link-netnsid 6
13: veth8a6256f@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 6e:93:98:36:a2:e5 brd ff:ff:ff:ff:ff:ff link-netnsid 7
14: veth964e25c@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether d6:c7:54:a6:c1:4a brd ff:ff:ff:ff:ff:ff link-netnsid 8
16: veth2b246c8@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 8e:5f:f7:7b:6e:72 brd ff:ff:ff:ff:ff:ff link-netnsid 10
17: veth7d6b930@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 6e:6c:5a:92:82:df brd ff:ff:ff:ff:ff:ff link-netnsid 11
19: vethc6e829f@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 7e:52:b7:e4:65:30 brd ff:ff:ff:ff:ff:ff link-netnsid 9
21: vethfdb5a19@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 3e:ba:89:9e:10:f7 brd ff:ff:ff:ff:ff:ff link-netnsid 4
23: veth6c99aae@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master home assistant OS state UP mode DEFAULT group default
link/ether 3a:20:01:f6:a2:3d brd ff:ff:ff:ff:ff:ff link-netnsid 0
the best candidate for the correct interface inside the container was is “enp1s0”, since it was the only interface (aside from “lo”) that is not a virtual bridge or veth interface.
Then, playing around with the settings I was able to determine these are the correct settings for each vlan in network (under network scanning settings) - (note my vlan designations earlier in this chain):
192.168.0.0/24 --interface=enp1s0 --vlan=1
192.168.20.0/24 --interface=enp1s0 --vlan=20
192.168.10.0/24 --interface=enp1s0 --vlan=10
Hope that helps other people running into this situatiuon. SOLVED!
Hi, good you got it solved!
Please take the time to mark the solution as the answer, you do that by selecting the three dots under the post:
Then select the check box:
By doing so:
Thanks for giving back to the community! 