I created a seperate zone to IoT devices. The intention is that
- IoT devices can only talk out to the internet.
- They should not be able to initiate connections into the rest of the lan (zone name is
trusted in my case).
- the other devices in the
trusted zone should be able to connect to IoT devices.
Currently I have the following zone setup:
It looks like traffic flows from trusted > IoT but not back. Any ideas on how to solve this?
I'm presuming that each zone needs to have conntrack=1 to enable flow state monitoring and know whether return traffic is allowed back into the source zone. Is this a correct assumption?
My "modem" zone has some similarities to your scenario and I solved it with masquerading.
Could that be a solution for you too?
Where are your inter-zone rules?
@iuncuim they are all in the same file. Here's the section that should enable this afaik.
@aboaboit I did try throwing the masq setting into the zone. But ideally I'd like to maintain a flat IP space than have NAT between zones.
1 Like
Thing is, masquerading also saves you from having to tell IoT devices about routing back to the originating network.
Let me guess: any one of these devices has a default gw and nothing more, right? In this case, what is the routing table like on your router?
1 Like
the interesting devices are br-trusted and br-iot.
root@w16gw:~# ip r s
default via 100.98.63.254 dev eth0.4 proto static src 100.98.2.7
10.7.8.0/24 dev wg0 proto kernel scope link src 10.7.8.1
10.7.8.2 dev wg0 proto static scope link
10.7.8.4 dev wg0 proto static scope link
10.7.8.5 dev wg0 proto static scope link
10.7.8.6 dev wg0 proto static scope link
10.7.8.7 dev wg0 proto static scope link
10.7.9.0/24 dev br-iot proto kernel scope link src 10.7.9.1
10.7.10.0/24 dev wg0 proto static scope link
10.7.11.0/24 dev br-trusted proto kernel scope link src 10.7.11.5
10.7.12.0/22 dev br-notrust proto kernel scope link src 10.7.12.5
100.98.0.0/18 dev eth0.4 proto kernel scope link src 100.98.2.7
172.31.240.0/20 dev ffvpn proto kernel scope link src 172.31.240.218
Uhm, in my case both the "modem" (aka your "IOT") and the lan ("trusted") are /24 but I don't think this is the issue. The gateway for the IOT devices is 10.7.9.1, right?
I might try to replicate your scenario on my guest lan, for the sake of curiosity.
@aboaboit correct: the IoT gateway is setup to be 10.7.9.1. Am I correct to assume that I define the two zones then I would define forwarding rules between them?
So the following
uci add firewall forwarding
uci set firewall.@forwarding[-1]=forwarding
uci set firewall.@forwarding[-1].src='trusted'
uci set firewall.@forwarding[-1].dest='iot'
uci commit firewall.@forwarding[-1]
is saying "allow traffic from Trusted to IOT, and allow return traffic if there is a session / flow setup?
I'm not sure I understand why you use "uci" directly instead of files under /etc/config but let's say my "lan" is like your "trusted" network (minus an input drop, I'd say) and my "guest" is your "iot". I did this way instead of using the "modem" zone since in that case the router is a DHCP client and I didn't want to mess with that.
All I had to do to get it to work is add "guest" to the allowed target zones for the "lan" firewall zone: placing my laptop in the "guest" wifi, I can ping it from my desktop in the "lan" zone but I can't ping it back. "w" on my laptop shows the real address of the desktop when I login via ssh, not the router (just to confirm that it is not masqueraded).
Here are the relevant bits:
config zone
option name 'lan'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'lan'
option forward 'REJECT'
config zone
option input 'ACCEPT'
option forward 'REJECT'
option output 'ACCEPT'
option name 'guest'
option network 'guest'
config forwarding
option dest 'wan'
option src 'guest'
config forwarding
option dest 'guest'
option src 'lan'
192.168.2.0/24 dev br-lan scope link src 192.168.2.1
192.168.3.0/24 dev br-guest scope link src 192.168.3.1
Try this setup, it should work.