The easiest way to do this is to put the HA server on the IoT network and then open (at least) the admin port that you'll use for control (8123 by default) from your main network to the HA server on the IoT.
You can even allow all connections from LAN > IoT but prohibit IoT > LAN (we're talking about initiating connections; responses are always allowed).
OK I will try this. I suppose in reality this means I move HA port from br-lan to br-iot device.
Meanwhile, it still seems that something is wrong. Wifi quality keeps degrading and for example, youtube app is basically unusable. My phone is this time connected to my ssid but at some point, it told me that private DNS server cannot be accsessed
Are you talking physical signal strength? or speeds? How specifically have you measured this?
Are other things working properly? Is it possible that your private DNS server (is it a PiHole or AdGuard system) is blocking things?
what network was your phone connected to and is that the same network is the private DNS server is using?
We can review your settings again...
speeds are drastically dropping, sometimes the connection is erratically dropping and reconnecting
I don't use anything beyond openwrt
When I don't need for some specifical reason to be connected to iot or quest I am always connected to my wifi ssid. When I say can not connect to private dns I just give the symptom. I suppose it means can not connect to openwrt server.
my own assumption is that the HA and iot devices overload the server in some way. Since the HA connections have not yet been set up correctly, many requests are submitted that do not receive a response - something like the effect of an accidental ddos attack. But maybe I'm not right.
Maybe we should review your settings again... can you post the 4 config files as they exist right now (just to make sure we're looking at the latest and greatest)
Is this only happening on Wifi, or does it also happen with wired connections? If wifi only, it is possible that this could be happening if your device isn't really happy supporting multiple SSIDs. Specifically, if you have the same radio tasked with two or more SSIDs, it basically has to rapidly switch between the two SSIDs, and that can reduce throughput and performance.
Ok... so the private DNS is just the standard DNS server that OpenWrt sets up for your lan(s) to use, correct?
So did you see this problem when connected to your main network's SSID or is it possible that it occured when you were connected to one of the other networks? This is key.
I don't think this is likely. Not impossible, but I'm pretty sure that any DNS or other requests that your HA server and IoT devices are making to your router are not sufficient to cause performance issues and it is unlikely they are happening at the rate and scale necessary to cause a DoS type situation.
I was thinking that maybe multiple ssid are too much but I have wrt1900ac. https://www.linksys.com/support-product?sku=WRT1900AC years ago this was not best but top of the price range.
exactly
I see this in 2.412 GHz which is now splitted but not 5.180 GHz I use it basically only with my laptop
for my latest setup files, I need to do some work with putty and manual cleanup. it is too late for that in here. probably tomorrow
thanks
This should be able to support multiple SSIDs.
Keep in mind that 2.4GHz is typically slower than 5G, so keep that in mind. You can always disable the extra SSIDs on the 2.4G radio and see if that improves performance.
k... post when you can.
I put the most recent conf file below.
Since HA is now located in the br-iot network, I tried to solve the fact that HA is now not accessible from the main network, and HA services cannot access the Internet with the last two firewall rules. Unfortunately, this approach did not work out, and HA remains at the moment isolated.
There are still some things that seem strange. The 4th port of the router has HA connected and 1st 8 port switch. When I moved the 4th port with HA to iot, for some inexplicable reason, the devices behind the 1 port switch stopped working, even though it didn't touch there anything. When I moved the 4th port back to the lan, the 1st port devices started working again.
As for speed issues, I know 2gh is slower than 5, but the problem is not that the connection subjectively feels slow. I have fiber until to the router at home, but yesterday, for example, the connection was so bad that the speed test refused to start at all. This problem is not constant either, because in the morning I could not use some services, but in the evening everything ran more or less properly.
I imagine that if there are no obvious errors in the setup, it would be necessary to get HA access to lan and wan to work, and then it will be seen, maybe the other problems will disappear by themselves.
root@WRT1900ac:~# cat /etc/config/network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fd27:f9b5:7706::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
config device
option name 'lan1'
option macaddr '94:10:3e:xxx'
config device
option name 'lan2'
option macaddr '94:10:3e:xxx'
config device
option name 'lan3'
option macaddr '94:10:3e:xxx'
config device
option name 'lan4'
option macaddr '94:10:3e:xxx'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
config device
option name 'wan'
option macaddr '94:10:3e:xxx'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
config interface 'wan6'
option device 'wan'
option proto 'dhcpv6'
config interface 'Quest'
option proto 'static'
option ipaddr '10.20.xx'
option netmask '255.255.255.0'
option device 'br-quest'
config interface 'IOT'
option proto 'static'
option ipaddr '172.16.xx'
option netmask '255.255.255.0'
option device 'br-iot'
config device
option type 'bridge'
option name 'br-quest'
config device
option type 'bridge'
option name 'br-iot'
list ports 'lan4'
root@WRT1900ac:~# cat /etc/config/wireless
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:02.0/0000:02:00.0'
option channel '1'
option band '2g'
option htmode 'HT20'
option cell_density '0'
option country 'EE'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option macaddr '94:10:3e:xxx'
option ssid 'Y'
option dtim_period '3'
option key 'xxxx'
option encryption 'psk2'
config wifi-device 'radio1'
option type 'mac80211'
option path 'soc/soc:pcie@82000000/pci0000:00/0000:00:03.0/0000:03:00.0'
option channel '36'
option band '5g'
option htmode 'VHT80'
option country 'US'
option cell_density '0'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option macaddr '94:10:3e:xxx'
option ssid 'Y5'
option dtim_period '3'
option encryption 'psk2'
option key 'xxxx'
config wifi-iface 'wifinet2'
option device 'radio0'
option mode 'ap'
option ssid 'YQ'
option encryption 'psk2'
option key 'xxxx'
option network 'Quest'
option dtim_period '3'
config wifi-iface 'wifinet3'
option device 'radio0'
option mode 'ap'
option ssid 'Y_iot'
option encryption 'psk2'
option key 'xxxx'
option network 'IOT'
option dtim_period '3'
root@WRT1900ac:~# cat /etc/config/dhcp
config dnsmasq
option domainneeded '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
option localservice '1'
option ednspacket_max '1232'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option dhcpv4 'server'
option dhcpv6 'server'
option ra 'server'
list ra_flags 'managed-config'
list ra_flags 'other-config'
option leasetime '1h'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
config domain
option name 'Thermostat'
option ip '172.16.xx'
config domain
option name 'Yoga'
option ip '192.168.xx'
config host
option mac '00:E0:20:xxx'
option ip '192.168.xx'
option name 'WIRELESS-AC1200'
option dns '1'
config domain
option name 'Smartplug'
option ip '172.16.xx'
config domain
option name 'Temperature_probe'
option ip '172.16.xx'
config dhcp 'Quest'
option interface 'Quest'
option start '100'
option limit '150'
option leasetime '1h'
config dhcp 'IOT'
option interface 'IOT'
option start '100'
option limit '150'
option leasetime '1h'
config domain
option name 'homeassistant_wifi'
option ip '172.16.xx'
config host
option name 'homeassistant'
option ip '172.16.xx'
option mac 'B8:27:EB:xxx'
root@WRT1900ac:~# cat /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'
config zone
option name 'lan'
list network 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
config zone
option name 'wan'
list network 'wan'
list network 'wan6'
option input 'REJECT'
option output 'ACCEPT'
option forward 'REJECT'
option masq '1'
option mtu_fix '1'
config forwarding
option src 'lan'
option dest 'wan'
config rule
option name 'Allow-DHCP-Renew'
option src 'wan'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
config rule
option name 'Allow-Ping'
option src 'wan'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-IGMP'
option src 'wan'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
config rule
option name 'Allow-DHCPv6'
option src 'wan'
option proto 'udp'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-MLD'
option src 'wan'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Input'
option src 'wan'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-ICMPv6-Forward'
option src 'wan'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
config rule
option name 'Allow-IPSec-ESP'
option src 'wan'
option dest 'lan'
option proto 'esp'
option target 'ACCEPT'
config rule
option name 'Allow-ISAKMP'
option src 'wan'
option dest 'lan'
option dest_port '500'
option proto 'udp'
option target 'ACCEPT'
config zone
option output 'ACCEPT'
option forward 'REJECT'
option input 'REJECT'
option mtu_fix '1'
list network 'Quest'
option name 'quests'
config zone
option name 'IOT'
option output 'ACCEPT'
list network 'IOT'
option forward 'REJECT'
option input 'REJECT'
config forwarding
option src 'lan'
option dest 'IOT'
config forwarding
option dest 'wan'
option src 'quests'
config rule
option name 'Quest DHCP DNS'
option dest_port '53 67 68'
option target 'ACCEPT'
option src 'quests'
config rule
option name 'IoT DHCP and DNS'
option dest_port '53 67 68'
option target 'ACCEPT'
option src 'IOT'
config rule
option target 'ACCEPT'
option dest 'wan'
option name 'HA to wan'
list dest_ip '172.16.xx'
config rule
option name 'HA to lan'
option dest 'lan'
option target 'ACCEPT'
list dest_ip '172.16.xx'
root@WRT1900ac:~#
Before I forget -- it is not necessary to redact the RFC1918 addresses in your configuration... they are often called "private" IPs, but that is only because they are not publicly routable.... they don't actually reveal anything sensitive about your network. Hiding them makes it harder for us to find/resolve issues.
Anyway, I'm seeing three issues:
On wifi, you have 2 different country codes set: EE (Estonia) for your 2G radio and US for the 5G radio. You should make sure that you are using the correct country code for your physical location so that you get proper performance that is within the regulatory requirements of your region. One (or both) of these is wrong, but I don't know where you are in the world, so I can only say: fix them.
(possible issue) I'm not sue if it is your intention to define domains for a bunch of your devices as compared to DHCP reservations. For reservations, the hostname and IP address are mapped as well as the MAC address so that the DHCP server can assign the correct IP to the correct device. Check the "domain" entries vs the "host" entries in your DHCP file.
For your HA server -- the problem is here:
Instead of dest_ip, these should be src_ip since the source is the HA server on 172.16.xx.yy.
I am not sure if I understand your question but when you ask about my given hostnames to devices it is bcs hostnames of lots of iot devices are really bad and in lots of cases there are no names at all so without that when I look at DHCP table I would not have any idea what is going on. There would just be a bunch of ip addresses without any additional information.
this was a bug but unfortunately does not completely solve connection problems. I see that HA still can't access any internet services for some reason. I really have no idea how HA services ask for the internet so I have no idea how to solve that.
I also don't understand how it is possible that devices that remained on the lan network like smartTV lost connection to wan now.
Is the HA server running in a docker container, as a service on another OS, or as its own 'bare metal' OS (HA OS)? Is the system using a manually assigned static IP or DHCP?
This doesn't make sense to me... is it wired or wireless? If you connect another system to that physical port or wifi network, does it work properly?
HA is on raspberry that was lying around
IP Address: 172.16.0.158/24
Gateway: 172.16.0.1
Method: auto
Name Servers: 172.16.0.1
TV is connected to ethernet port lan1 and HA is connected to lan4. Lan1 (maybe also lan2 and 3 I have not tested) loses connectivity as soon as I move lan4 from br-lan device to br-iot. And no it's not a device issue, lan does not function anymore
Is the Pi running Raspberry Pi OS or HAOS? If RPiOS, is it running HA in a docker container or as a service directly installed?
So let's see the before (working) and after (broken) network config file to figure out what is going wrong.
Actually, I tested. All lan ports 1-3 stop working
Based on that...
It should be haos. I used HA instructions for raspberry
broken version is the latest and working is one before that (that one w fast transition still on and Quest DHCP DNS rule missing) but fast transition is not an issue here bcs lan ports worked until yesterday when I moved nr4 to iot
for the sake of clarity and ensuring that we are absolutely looking at the right info, would you mind posting the latest config as it exists on your router right now from the working context, and then again from when it stops working? If this is related to the lan port assignments, we should only need the /etc/config/network file.
The not working is the latest as I said. I made and posted it today.
I should be able to make changes and create also working version again
So you're saying that this does not work:
but this does?
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
...
config device
option type 'bridge'
option name 'br-iot'
And more specifically, the former causes all ports to stop working, while the latter allows all ports to work as expected?