At the moment I've got two SSIDs, IoT and IoT-WAN, to separate the IoT devices that don't need internet access, such as my cameras, and those that do, like my Echo Dots. These then have their own firewall zones and interfaces, as shown here:
Would it be possible to have a single SSID which defaults to either allowing or blocking WAN access, and then set rules for specific devices which override that default setting?
I believe so. My setup is using VLANs with different SSIDs. The IOT VLAN/SSID has no access out to the WAN unless a specific firewall rule permits it. My setup is not perfect and I understand that policy based routing would be more flexible as I am only allowing connections out to specific numerical IP addresses based on the IP of the IOT device. My setup does not work with DNS requests where the target address changes frequently, so I have to constantly update the dest_ip in the rule.
Thanks. I'm not sure it matters but I've read some posts that suggest that minimising the number of SSIDs reduces the chances of the router crashing/rebooting, so I'm just trying to use as few as possible.
Is your IoT firewall zone using the same settings as shown in my screenshot, and then you just override those default settings by creating Traffic Rules which allow specific devices on the IoT network, identified by their MAC addresses, to access the WAN?
I was trying to setup some smart plugs on my IoT SSID earlier and I was able to see the hotspot they create during setup and connect to that with my phone, and then enter the details for the IoT SSID for them to connect to, but then the apps got stuck in a loop so I figured that the devices must need access to the Internet, at least during the setup stage, and I had to connect them to the IoT_WAN network to get them working.
If none of my smart devices will work unless I allow them access to the Internet there's not much point having an IoT network that blocks access, but using the IoT_WAN one will still keep them isolated from my lan and each other. Maybe I can find a way to allow the devices to temporarily access the Internet just during setup and then block access the rest of the time.
Would assigning a static IP to IOT devices you do not want to have internet access, then blocking WAN access for that device based on its MAC address and static IP with a firewall rule work for you?
in /etc/config/dhcp you would add something like this to define a static ip:
config host
option name 'IOT-Device-With-Static-IP'
option dns '1'
option mac 'xx:xx:xx:xx:xx:xx''
option ip 'x.x.x.x'
For a zone named iot for your IOT interface/subnet, The firewall rule would look like this in /etc/config/firewall:
config rule
option name 'Block-IOT-Device-From-WAN'
option src 'iot'
option dest 'wan'
option target 'REJECT'
list proto 'all'
list src_mac 'xx:xx:xx:xx:xx:xx'
list src_ip 'x.x.x.x'
IOT devices with WAN access and without would still be able to talk to each other, so this may not be what you want. But if you just want to block specific devices from having WAN access, this will do it.
Thanks, that looks like it would work for me and I could just disable the firewall rule if necessary when setting up the device.
Wouldn't the "isolate devices" option in the IOT SSID settings prevent the devices talking to each other?
Yes. But it's all-or-nothing. Isolate clients means that no devices on that wifi SSID will be able to talk to teach other. Depending on the specifics, some controllers (like Alexa or Google Home) need to have a local connection to the device they are trying to control such as smart bulbs/outlets and the like. Isolate clients will break that functionality.
Oh right. That might explain why my smart device apps were working but the Alexa app said that they were all non-responsive.
I guess being able to prevent some devices accessing the Internet (primarily cameras) is more important than preventing them talking to other IoT devices.
Does the point about isolating clients solve your other thread?
Yes. Again, not optimal because if the IP the camera wants to use from pushx.reolink.com is not defined in the rule, it does not work. So there are times when that IP changes and I have to update the rule. As I said above, policy based routing is needed but I haven't bothered with it yet.
Zones:
IOT --> reject | reject | accept | reject
Yes, there is an allow rule like:
config rule
option src 'iot'
option target 'ACCEPT'
list proto 'tcp'
list proto 'udp'
option dest_port '53 67 68 123'
option name 'iot dhcp dns and ntpd'
option family 'ipv4'
config rule
list proto 'udp'
option src 'iot'
option dest 'lxc'
option dest_port '53'
option target 'ACCEPT'
option family 'ipv4'
option name 'IOT DNS whitelist'
list src_ip '10.9.5.108'
list src_ip '10.9.5.106'
list src_ip '10.9.5.102'
list src_ip '10.9.5.107'
config rule
list proto 'tcp'
option src 'iot'
option dest 'wan'
option target 'ACCEPT'
option dest_port '443'
option family 'ipv4'
option name 'doorbell push notification'
list src_ip '10.9.5.108'
list src_ip '10.9.5.102'
list dest_ip '34.194.168.247'
list dest_ip '54.160.26.193'
Yes thanks, that seems to have been the problem.
Thanks for sharing your allow rule, that's helpful.
I wonder if we could address this problem by using Pihole or Adguard Home to limit a client's access to specific domains, so that we don't have to mess around with IP addresses in the OpenWrt firewall?
I think some builds of OpenWrt include an adblocking plugin, but I don't know if it's as good as Pihole or Adguard. The R7800 NSS build that I'm using doesn't have any adblocking plugins, but I'm running Adguard Home on my tiny PC server and also a RPi to provide redundancy in case the server is down, and I'm going to install the same at my Dad's house soon, so I'll have to investigate whether I can do this with Adguard.