How to create correct firewall for IoT

[psherman]

@catdogmaus

I added it now but basically, it is what it says: allow incoming ipv4 and ipv6 from IoT to homeassistant IPxxxxxxx

You only need IPv4. Did you post the rule that you created? If not, please post it so that I can comment on the specifics.

@catdogmaus

Question. When I move all ports to quest zone and create the rule that allows to main lan everything that contains my mac addresses all ethernet sockets should be available to me and also for quests?

For your use (I'm assuming you don't have a managed switch), each port should be assigned to only one bridge. So you can have any arrangement of the 4 ports as long as each port only shows up in one bridge. This is because you can only have a single untagged network on a port (this is known as an access port), and normal ethernet devices will almost always expect untagged networks.

If you wish to carry multiple networks on a single physical port, this is called a trunk port and is done by adding 802.1q VLAN tags to identify the ethernet frames that belong to each network. Most end devices do not expect tags and typically will not know how to use them. Therefore, you need a managed switch or other VLAN aware device if you are using VLANs and trunk ports -- the managed switch allows you to setup additional access ports to 'break out' the networks from the trunk.

@catdogmaus

'm also asking if the IoT firewall setting is enough to close the IoT device zone from both internet and main lan or something else should be changed.

The IOT firewall zone looks fine based on what you have showed.

[hmof]

I put my HA server on both my main subnet (VLAN) and IoT subnet (VLAN), so that I can use it easily but it can also communicate with the IoT devices. Then no firewall exceptions are required.

[psherman]

That is a reasonable option, provided that you are not worried about the HA server becoming a potential conduit between the networks (this isn't likely, but any system that is connected to both networks can become a liability under the right circumstances).

[hmof]

I'm not really sure what solution the OP has settled on, but it's worth adding too that HA really needs to be on the same subnet as the IoT devices because a lot of the IoT protocols and particularly discovery depend on broadcasts and therefore being in the same subnet.

It is possible to bridge mDNS across subnets with Avahi but that won't fix everything.

[eduperez]

May I ask what you did to put a device on two different networks, please?

[hmof]

I don't use the Home Assistant OS, so maybe this won't help. But I have the server connected to a trunk port and I simply set up two VLAN interfaces in Network Manager.

In Home Assistant system settings you can tell it which network interfaces to use.

[catdogmaus]

My problem at the moment goes a little beyond the topic here, but is much more annoying and relevant. I have a wrt1900ac, as soon as I restart the router, or there is electrical outage, basically all connection is lost. Everything seems fine but LuCI overview shows that there are no active DHCP leases. Ping, traceroute and nslookup are OK. Server never fully reciovers. Only way I found it possible to get things work again is clean install and all settings rebuild until next restart.
I can create new topic or maybe here somebody knows possible reasons.
Thanks

[psherman]

@catdogmaus

Everything seems fine but LuCI overview shows that there are no active DHCP leases.

This is expected behavior since the dhcp lease table is stored in ram. It is lost on a power outage or reboot.

Can you describe the specific problem that you encounter after a power event?

[catdogmaus]

Obviously is loss of all connectivity a problem. Router should give out new leases but never does, I don't know if this is the cause or just a symptom.

[psherman]

@catdogmaus

Router should give out new leases but never does,

The router will only give out new leases if they are requested by the dhcp clients.

So, the important question is this: do the clients still believe they have an active lease? If so, they will not request a lease renewal until at least 50% of the lease time has elapsed. A quick way to know the status is to look at the network config of a client on the network. Does it have a normal address? Or is the address something that begins 169? The latter means it was unable to obtain a lease. The former means it still thinks it has an active lease.

[catdogmaus]

Your comment about client addresses made me look in that direction, and although everything seemed fine with the addresses, it turned out that when the router was restarted, all clients marked now AP/extender as their DHCP address provider. However, the AP is prohibited from issuing a DHCP lease. After the router came back online, according to clients, the AP was still the dhcp lease manager. That's how the whole network was broken. Unfortunately, it is not possible to install OpenWrt on my AP, so it will take some time before it can be replaced with better hardware.

[psherman]

@catdogmaus

the AP was still the dhcp lease manager.

Well, I think we have a root-cause. You don't necessarily need to install OpenWrt in order to fix this... you just need to make sure that the DHCP server is disabled on your AP (or if you cannot disable it, at least make sure it advertises the correct gateway and DNS addresses, and then disable the DHCP server on your router (there should only be one DHCP server enabled on the network).

Given this, I suspect that your problem is solved (at least from the perspective of this thread)... is that correct? If not, please explain what other issues you have. But if it is resolved...

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

[catdogmaus]

I already decided that my problem was solved, but the last test revealed that I simply can't connect to the IoT wireless network. Everything seems ok, the settings are basically identical to the quest network, just the devices refuse to connect. it drives me crazy. I will also put a summary of the most recent settings here.
The only wireless network that I can connect to at moment is for some reason quest wifi

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'
        list ports 'lan4'

config device
        option name 'lan1'
        option macaddr '94:xxx'

config device
        option name 'lan2'
        option macaddr '94:xxx'

config device
        option name 'lan3'
        option macaddr '94:xxx'

config device
        option name 'lan4'
        option macaddr '94: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: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.xxx'
        option netmask '255.255.255.0'
        option device 'br-quest'

config interface 'IOT'
        option proto 'static'
        option ipaddr '172.xxx'
        option netmask '255.255.255.0'
        option device 'br-iot'

config device
        option type 'bridge'
        option name 'br-quest'
        option bridge_empty '1'

config device
        option type 'bridge'
        option name 'br-iot'
        option bridge_empty '1'

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:xxx'
        option ssid 'Y'
        option dtim_period '3'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'
        option encryption 'psk2'
        option key 'xxx'

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:xxx'
        option ssid 'Y5'
        option dtim_period '3'
        option encryption 'psk2'
        option key 'xxx'

config wifi-iface 'wifinet2'
        option device 'radio0'
        option mode 'ap'
        option ssid 'Y_Q'
        option encryption 'psk2'
        option key 'xxx'
        option network 'Quest'
        option dtim_period '3'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

config wifi-iface 'wifinet3'
        option device 'radio0'
        option mode 'ap'
        option ssid 'Y_iot'
        option encryption 'psk2'
        option key 'xxxx'
        option network 'IOT'
        option ieee80211r '1'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

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 '192.xxx'

config domain
        option name 'Yoga'
        option ip '192.xxx'

config host
        option ip '192.xxx'
        option mac '2C:F4:xxx'
        option name 'Thermostat'
        option dns '1'

config host
        option mac '00:E0:xxx'
        option ip '192.xxx'
        option name 'WIRELESS-AC1200'
        option dns '1'

config domain
        option name 'Smartplug'
        option ip '192.xxx'

config host
        option name 'homeassistant'
        option ip '192.xxx'
        option mac 'B8:27:xxx'

config domain
        option name 'Temperature_probe'
        option ip '192.xxx'

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 host
        option name 'Samsung'
        option mac 'D8:xxx'
        option ip '192.xxx'
        option leasetime '15m'

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 'Allow IoT to HA'
        option src 'IOT'
        list dest_ip '192.xxx'
        option target 'ACCEPT'

root@WRT1900ac:~#

[mmstano]

Turn off fast transition. A lot of IoT devices don’t play well with 802.11r. Besides, your IoT devices are more than likely stationary and don’t require it anyways.

EDIT: for example, my ring cameras won’t connect to my IoT network wifi with fast transition on. I’m assuming you’re experiencing the same thing.

[catdogmaus]

This time it is not about fast transition. nothing connects! phone, tablet, In addition, the same connection problems occur randomly with my home wifi (ssid Y). The network actually worked as long as there was one wifi. problems arose when I divided the network into three.

[mmstano]

It may be worth trying if you haven’t and if you’re using 22.03. You never know unless you try

[psherman]

I agree with @mmstano -- turn off fast roaming. It has the potential to make connections difficult or impossible in general since there are many devices that just don't work well with it enabled. This should be priority to disable and test.

[catdogmaus]

Of course, I tried it, it's just a few clicks. Unfortunately, there was no positive result. The IoT wifi is still unavailable. In fact, the guest network that worked was also on fast roaming. I removed it from everywhere for now.

[psherman]

@catdogmaus

config rule
        option name 'Quest DHCP DNS'
        option dest_port '53 67 68'
        option target 'ACCEPT'
        option src 'quests'

It appears you don't have an equivalent rule for allowing the IOT zone to get DHCP and DNS services from the router. This would cause clients to connect, fail to obtain a DHCP lease, and then disconnect because of that.

[catdogmaus]

Thanks this was the reason for the connection trouble. Now there is still the problem to resolve why I initially started this thread.
How do I securely connect home assistant to the IoT network? As it seems, a simple firewall rule is not enough.
hmof told above: HA really needs to be on the same subnet as the IoT devices because a lot of the IoT protocols and particularly discovery depend on broadcasts and therefore being in the same subnet.
HA also must reach the internet for several of its services. So I somehow need to give it both without compromising the IoT network.