I want to find a way to achieve all of the 4 following if possible:
1/ have trusted and untrusted devices in separate network interfaces
2/ allow untrusted devices to access trusted devices
3/ prevent untrusted devices from accessing the WAN
4/ be able to control the untrusted devices with my trusted phone and computer
So far, I am ok with 1/ and 3/ I think
1/ My trusted devices only have access to 5GHz wireless and the first 3 LAN ports of VLAN1. They are bridged in the existing LAN interface (subnet 192.168.1.1).
My untrusted devices only have access to 2.4GHz wireless and the 4th LAN port of VLAN3 (wired to a non managed switch). I created a new interface called IoT where they are both bridged (static address, subnet 192.168.2.1)
3/ I created a new firewall zone which cover the IoT network and in which nothing is forwarded to destination zone WAN
I am not sure about 2/ and 4/ though...
2/ I thought I just needed the new IoT firewall zone to allow forward to destination zone LAN and from source zone LAN. I have a music streamer (untrusted) that needs to access music on media server (trusted). The streamer sees the server, I can browse files, but it only plays the first second of each song...
4/ My phone and computer are on a different network interface, they are both on the 5Ghz wireless. My phone can control the music streamer through an app when everything is on a same interface, it can't see the streamer when on a different interface... is there any way around this? Maybe I will need to trust the streamer
Short of putting untrusted devices on a separate interface and firewall zone, what would be the best way to stop the untrusted devices from communicating with the WAN? Traffic rules..?
It seems to me that your problems are mostly because the devices are no longer in the same broadcast domain, hence the broadcasts don't work. If there is option to work with unicast packets in different subnets then this is what you should select.
Yes, rules to block the mac of the untrusted device (in order to cover both ipv4 and ipv6) from accessing the internet is a good way.
For now, the only place in Luci where I see a mention of unicast is in Network > Static Routes.
If I add a rule, I am given a few options: interface, target ("Host-IP or Network"), route type (one of the option is unicast), route table, source address...
I haven't wrapped my head around what static routes do, but do you reckon I am looking in the right place?
I will have to do a bit of reading anyway.
Otherwise, if this isn't an option, I will set up traffic rules based on MAC addresses..
Hi Trendy, give me a couple more days to understand firewall traffic rules and play with them. I'll come back to this thread to give more details and mark it as a solution if appropriate
Ok, so I looked into setting traffic rules but I am struggling a bit.
How do I set rules so that a device is blocked from accessing WAN and the WAN is blocked from accessing the device.
Here is what I have in /etc/config/firewall at the moment:
config rule
list proto 'all'
option dest 'wan'
option src 'lan'
list src_mac '00:19:R1:FG:88:MK'
option target 'REJECT'
option name 'reject-allproto-audioreceiver-out'
config rule
option src 'wan'
option name 'reject-allproto-audioreceiver-in '
option dest 'lan'
list dest_ip '192.168.1.12'
option target 'REJECT'
list proto 'all'
Unfortunately these settings don't block anything, I can still stream internet radio with the audio receiver.
I looked for inspiration in here, but it didn't help so far.
It is probably a silly omission from my end!
The first rule is correct. Is the mac address correct?
The second rule is useless. If you don't enable a port forward the internal IPs are not accessible, furthermore there should be no forwarding from wan to lan.
This is a fake MAC address that I choose just for posting here.
I checked, I did pick up the right MAC address from the Luci drop down menu, that same address appears in the firewall file in /etc/config.
Does each line have to be in a specific order..?
I just deleted the rule, re-created it in Luci and now I've got the same lines but in a different order.
My device can stream radio from internet (I never use the radio, so I don't mind losing it), shouldn't it be silent with that rule on? Right now, the radio is playing...
I want that device to have no interaction whatsoever with internet.
Yes, line order matters. If you accept something on the first line and drop it on the second line, it will be accepted.
Post the whole firewall config, as well as the iptables-save -c
Before I put you through the trouble of looking at my firewall config and iptables, I want to make sure I expressed myself clearly when I said lines now are in a different order. I basically deleted the rule I had added in Luci. Here is that previous rule entry in /etc/config/firewall as a reminder:
config rule
list proto 'all'
option dest 'wan'
option src 'lan'
list src_mac '00:19:R1:FG:88:MK'
option target 'REJECT'
option name 'reject-allproto-audioreceiver-out'
And then I added it back in Luci again. Here is the new entry in /etc/config/firewall:
config rule
list proto 'all'
option name 'reject-allproto-audioreceiver-out'
option dest 'wan'
option target 'REJECT'
option src 'lan'
list src_mac '00:19:R1:FG:88:MK'
As you can see, most lines are listed in a different order.
So when you say line order matter, do you imply that the firewall rule won't work if each line is not where it should be? If so, Luci possibly has a problem then.
We are talking about different things. The order of the lines you meant doesn't matter. All of them must match for the rule to be accepted or denied or whatever.
I was talking about the order of multiple rules, where one might drop and the next might accept the same thing, but it will be dropped due to the fact that it is higher.
I figured what I was doing wrong in the end.
I am running a VPN client on my router and all my devices are set to go through it to access internet. So, when setting traffic rules, I needed to select the VPN as the "Destination zone" in Luci, not the WAN. It was as simple as that.
Now, the rule looks like this in /etc/config/firewall:
config rule
list proto 'all'
option name 'reject-allproto-audioreceiver-out'
option dest 'vpn'
option target 'REJECT'
option src 'lan'
list src_mac '00:19:R1:FG:88:MK'
vpn is the name of the network interface I created.
It now prevents my device from streaming internet radio.
I also have some lights for which I set a traffic rule, they are also not accessing internet.
The firewall rules works now!
Is there any advantage to choosing reject over drop by the way?
Reject notifies the host that it was dropped.
Drop silently denies the traffic.
Drop is better in your case, there is no need to notify the hosts, as this won't stop them from retrying.
I should note that a single radio, say 2GHz, can have multiple SSIDs, and each can be associated with a different OpenWRT "interface". This allows you to have a 2GHz network for TrustedStuff and a seperate 2GHz network for UntrustedDevices
Indeed, but I don't need any of the trusted devices to be on the 2.4GHz, so the existing 2.4 could be used just for untrusted devices.
But, like I mentioned, earlier in the thread, I have opted to create firewall traffic rules to block the IoT devices from accessing internet.
Initially, I thought about
1/ having two distinct network interfaces, one bridging eth0.1 and wlan0 for trusted stuff, another bridging eth0.3 and wlan1 for IoT stuff.
2/ creating a firewall zone for the IoT network with no forwarding to the WAN.
The problem here is that my phone is on the 5 GHz and acts as a remote for devices on the other network.
