[aaronburro]

I've grown tired of my ISP's crappy router and the limitations it imposes on me. So, I've got a tri-band router with DD-WRT that I'm going to DMZ off of the ISP router and host my network off of that.

My end goal is to have three networks, accessible from SSIDs on each wireless interface (as in, I would have 9 total APs):
1) My main network (which has an ad-blocking DNS server)
2) An IoT network, fully accessible from the main network, but with outgoing traffic blocked for all but a few services (SMTP, NTP)
3) A guest network, with no accessiblity to/from the other two networks, except for the local DNS

The first network is implemented as the physical interface of each wireless interface, bridged as normal. The second network is implemented as the first VAP on each wireless interface, bridged onto br1. The third network is implemented as the second VAP on each wireless interface, bridged onto br2.

br1 and br2 are implemented using the normal bridge features in Setup --> Networking. Using DNSmasq, I've got IP addresses being served up correctly across the bridges. I'm using a KONG build, so I've got the NAT / masquerading available and enabled.

Questions
1) I made the bridges so that I don't have to duplicate firewall rules for each interface (e.g., wl0.1, wl1.1, wl2.1). Will this work as I hope it does, or will I have to create separate rules for each interface?

2) Net Isolation for br2 doesn't seem to be working on its own, so I've given it a helping hand by DROPping the FORWARD chain to and from br2. I'm also blocking the INPUT chain from br2 for all ICMP messages, as well as telnet, ssh, www, and https. (I don't understand why the FORWARD rules don't take care of this already, though...) Is there anything else I need to block for proper segmentation of the guest network from the rest of my network?

3) As my IoT devices are currently on the same subnet as my main network, there's going to be a transition period as I move them. I will have to update static addresses across several devices, and it'd be nice to have them continue to work with the old and new addresses for a short period. Is DNAT via PREROUTING how I would accomplish this?

4) This is a bonus request... I'd like for my IoT devices to be "discoverable" from the main network, the same way they are today. I assume this happens via broadcast of some sort, as I've got UPnP totally disabled on my networks. How would I go about achieving this? Is it a simple FORWARD rule? If I make my main and IoT networks exist within the same subnet (e.g., 255.255.254.0), will that allow broadcasts to propagate across both networks? Or is this the kind of thing where I'd have to pull out wireshark and see how they are working in painful detail?

5) What am I missing? I mean major stuff. Are there any gotchas that I need to look out for, or major gaps in my plan?

Thanks for all the help in advance.

[egc]

1. Yes put wl0.1 wl1.1 etc on their own bridge br1 and take it from there

2. FORWARD does not take care of the INPUT (router itself), for INPUT I block everything and only enable ICMP (but do not if yo want not) , DNS and DHCP:

[aaronburro]

So, it sounds like I should just turn off Net Isolation and do it by hand.

I'm not so worried about totally separating the IoT devices from the main network, as opposed to just creating a simple way to add firewall rules for all IoT devices in one fell swoop. Those things weren't built with security in mind, so I don't want them making connections out of my LAN, except to very specific places. If they stay on the same subnet, broadcast should still work, right? So, say I set up a 192.168.8.0/23 subnet, and put my main devices all on *.*.8.* and the IoT devices on *.*.9.*, broadcast should still work, right? Assuming the device manufacturers didn't do something stupid like assume a 24 subnet.

Also, forgive me if this is a stupid question, but I'm drinking from a firehose wrt iptables. Doesn't your ICMP INPUT rule allow pinging across the bridges? Or is that blocked by the FORWARD rule, so that guest devices would only be able to ping the router and hosts upstream of it?

[egc]

INPUT rule is only for the router itself so FORWARD blocks icmp across bridges (and thus accros WAN)

I am a bit worried that some stupid iot things have a hard coded netmask of 255.255.255.0 and can not handle the 255.255.254.0, but wait for @eibgrad's advice he has superior knowledge .

You can of course use /24 subnet and "segment" it in /27 pieces, like 32/27 which will give you 32 - 63 as to easily make the firewall rules.
(that is why a lot of use use a DHCP range of 64 - 127 = 64/26)

I hope you can make sense of this, but otherwise @eibgrad will explain it in more detail

[aaronburro]

Almost nearing the finish line. The only hiccup I've had is with DHCP for the IoT segment. Statically defined leases work fine, but dynamic ones fail. I suspect it's due to the overlapping address space (I'm trying to use a /23 subnet, and only hand out leases for the first network on br0, while handing out leases for the second one on br1. I suspect this scenario isn't supported). I had to set the subnet of br1 to /24, instead of the /23 that the main segment uses, otherwise the router soft bricked.

I see some squirrelly business with MACs, and I don't know if that's a problem. The following sets of interfaces have the same respective MAC on the Setup --> Networking page. Is that a problem?

1) br0, br1, br2, eth0, eth1 (wl0), vlan1, wl0.1
2) eth3, wl2.1

Second, does the below set of firewall rules look sufficient to do what I want? I'm most interested in the IoT segment. I'd like it to allow full access from the main segment, but only be able to send out data on established connections to the main segment.

[egc]

I can vaguely remember that DDWRT had trouble dealing with /23 addresses, I think the router had to be in the first /24 address space and so should the DHCP range be.

Static leases should always be outside the DHCP range for DDWRT.

I have seen the same MAC address before but have a close look at the MAC addresses as these should be virtual local MAC address the second digit should different. It should be a 2,6,A or E, like xE-xx-xx-xx-xx-xx

@Eibgrad knows more about these rules so wait for his comments.

[SurprisedItWorks]

I assume you want devices on your guest network isolated from each other. Certainly enabling AP isolation on of its two VAPs is a start. That will keep two devices on the same interface from seeing each other. But I suspect you'll find that devices on one VAP can see devices on the other VAP, because they are bridged together. So do test it. I'm not sure you can fix this at the firewall level, because it seems like (i.e. this is how I mentally model things to account for some oddities I've seen) packets don't even go through the firewall until they leave the bridge.

I worked around this on my system by putting my two guest VAPs (on two wifi bands) on separate unbridged subnetworks and just giving them each AP isolation and including them in my firewall approach to net isolation.

All this is shaky in my mind, as this is not an area in which I am more than a rank amateur, so please weigh in egc, eigbrad, or others if you can clarify or even just tell me I'm all wet and there's no problem!

[aaronburro]

[egc]

Iptables indeed only works when crossing bridges
You can use ebtables (that is how AP isolation works) but it is very resource intensive and can be a little buggy.
But indeed you can try it

[aaronburro]

For anyone who tries the ebtables approach, it works ok, but I find (at least on kong r38580 build) that I often need to reboot after applying the firewall script.

Also, on the duplicate MAC front from earlier, I found that I had a LOT of VAP settings hanging out in nvram, even after doing an "nvram erase". That caused all kinds of stuff to go squirrelly. I manually removed all the VAP entries. When I went back and recreated the VAPs, they all had unique addresses. I then assigned the wl0's MAC to br0, wl0.1's MAC to br1, and wl0.2's MAC to br2. After this, things began going much more smoothly.