Help separating vlans for iot and smart-tvs ?

I have upgraded my network equipment and changed my old home wireless router and access point with two mikrotik HAP AC2. One acts as a main router, connecting to the internet, and the second HAP AC2 has been configured as a basic AP, in the same subnet. The connection between them is done with a gigabit ethernet link.
The internet connection is tagged with the provider assigned VLAN, which is already done.
Basic configuration is working great, wlan are configured with different ssids for 2.4GHz and 5GHz bands and wifi coverage is great, with even more performance than with the old routers.

Now I want to migrate my IOT and smart-tv&speakers to separate VLANs, something like other users do nowadays as our home networks keep growing.

I guess that I have to (almost) duplicate the bridges wlan and VLAN configuration on both HAP AC2s, then reconfigure the ethernet link between them with a “trunk”" port on each router(switch).

Very common approach.
My home vlan is 11 and that covers both wired and wireless (and can be tied to specific SSIDs and usually jusgt 5ghz)
My IOT vlan is 15 for both wired and wireless (on separate SSIDs usually just 2ghz)

I have numerous other vlans to separate specific computers or devices on the wired side

All my vlans have internet access only.
Home vlan has a printer on it.
Some vlans (other isolated PCs) have access to the shared printer as well.

ONly the admin computer (desktop) and laptop have access to the router itself for admin purposes
Only the admin computer has access to all vlans.
All the vlans have access to the router itself for ONLY port 53 (DNS).

Etc.

Best guide…
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1

I have wondered the same thing. A concern I have with doing this is that a lot of devices these days rely on the app being able to see the device on the network in order to communicate. Is this possible with the separate VLAN’s?

I’m wanting to set up a system for my Dad, as he’s been complaining to me about his network every time I go over there, but if it messes with things being able to communicate then I’ll just get more complaints!

Hi you would need to be more specific!
The only device with issues in that regard are SONOs speakers which are a pain.
Most other apps are not problematic, but without more detail its hard to assess.
I use tons of apps for different devices and the thing is.
DEVICES TALK TO THE INTERNET ON THEIR OWN VLAN but to the cloud.
When you open your app up on your phone or PC, you connect to the internet on probably a different vlan and talk to the cloud.
(some devices also permit bluetooth direct to device so that is not affected by router)

In other words, devices and your phone have a happy copulation in the cloud. :slight_smile:

When using this VLAN separation, everything that uses stuff like mDNS, Bonjour (Apple) or multicast based service discovery will (probably) break.
Mikrotik has no “relay” function for these protocols/services (eg. implementation of Avahi) across different VLAN’s.
That traffic with a TTL=1 was never designed to “leave” the local LAN.

If there’s a NAS on the network that supports virtual interfaces, VLANs, and Bonjour, then Avahi might be available and usable to sidestep the Bonjour challenge. In my setup, IoT, shared devices (e.g., printer, TV for Air Play), my and my wife’s personal devices, guest/kid devices, and security cameras are all separated on different VLANs. For shared devices requiring Bonjour, I created the applicable VLANs and enabled the Avahi reflector all on a Synology NAS. The NAS firewall is used to restrict access to its resources. Of course, if there isn’t already a device on the network that can be used as a reflector, then addressing the Bonjour use case won’t be as convenient.

Doesn‘t this introduce bridges between the various networks which can potentially become security holes ?

Lars

Potentially/theoretically yes. You are in effect “short cutting” your firewall. So you must manage the firewall on the Synology NAS to really restrict it to only the required traffic. So you only want to pass certain multicast ranges I guess here.

My particular model, which has only one LAN port, doesn’t bridge the logical interfaces as far as I can tell, so the only traffic that should be passing between VLANs is Bonjour mDNS that is actively replicated by Avahi. This does require enabling Bonjour on the NAS firewall (port 5353), but all other traffic for VLANs that don’t access the NAS is dropped in the NAS firewall.

I had understood the NAS would have to be attached to the two (all) VLANs between which the Avahi service would forward traffic ? Wouldn’t any vulnerability of the Avahi service permit an attacker to get access to other VLANs in such a scenario ?

Lars

Correct, Avahi has to be connected to all VLANs, but Avahi itself only passes mDNS traffic. All traffic that follows still moves through the router. For example, I have to create special ROS firewall rules to get the handshake to work for Air Play mirroring, and access to a Bonjour enabled device (e.g., printer) can still be restricted using the ROS firewall. True, a compromised Avahi service might be able to pass additional traffic between VLANs, but if Avahi were able to be compromised to that extent, then I would think that the NAS itself, which has to be connected to all VLANs for Avahi to be, was significantly compromised first. Avahi would be the least of my worries at that point.

Hi @awbl, I’m very interested to achieve the same - including the Avahi reflector through Synology NAS mirroring. Would you be able to share your (proto)configuration as an example?

Thanks in advance.

I’m not sure how far you’ve gotten, so apologies if you already figured some of this out. I’m assuming you’re familiar with SSH and sudo, which you’ll need to set up the NAS. Also, you may want to consider using a Raspberry Pi, so you don’t have to mess around with your NAS. I’ve been using my Synology as a reflector without issue but am considering switching to a Pi now that I’ve used one for Pi-Hole. Reflector setup should be very similar if not identical between the two.

That said, you’ll first need to establish the VLANs your Synology. How you do this will depend on your model. A search for “Synology multiple VLANs” will yield multiple sites that provide a walkthrough. I used the approach that involves creating a duplicate ifcfg file in /etc/sysconfig/network-scripts. Note, most overviews out there involve bonded interfaces, but it’s the same for more basic models with a single Ethernet interface. The files and interface are just named with “eth” instead of “bond.” I also suggest looking up how to physically reset the network configuration on your NAS. It’s a lifesaver if you accidentally screw something up. Bear in mind that once you do this, you can’t really change anything via the Synology UI. To delete or change a VLAN, you’re stuck with shutting down the VLAN interface and deleting or modifying the ifcfg file via a SSH session.

Once the VLANs are in place, enabling the reflector is as simple as editing /etc/avahi/avahi-daemon.conf to change the line “#enable-reflector=no” to “enable-reflector=yes”. I suggest enabling the Synology firewall if you haven’t already to deny access to the NAS for anything that otherwise wouldn’t normally have access. For the reflector, you just need to make sure the Bonjour service is allowed for any applicable IPs.

On ROS, you’ll need to put some rules in place for everything to work depending on your firewall setup. If all traffic is allowed to flow between your clients and AirPlay devices, then I think you may be set. In my case, the client must initiate a connection before a device can send anything back. Unfortunately AirPlay doesn’t seem to work like other traffic where a client can simply establish a connection that’s then tracked through connection tracking (e.g., printers). There’s some traffic related to initializing the session that seems to actually require the device to be allowed to establish the connection. As a workaround, I use the following rules to temporarily add the client and device to an address list, so the device can establish a tracked connection in ROS to do the initialization. Once the session’s up and running though, the normal firewall rules apply.

/ip firewall mangle add action=add-src-to-address-list address-list=AirPlay_Mirroring address-list-timeout=1m chain=prerouting dst-port=7000 protocol=tcp

/ip firewall mangle add action=add-dst-to-address-list address-list=AirPlay_Mirroring address-list-timeout=1m chain=prerouting dst-port=7000 protocol=tcp

/ip firewall filter add action=accept chain=forward dst-address-list=AirPlay_Mirroring src-address-list=AirPlay_Mirroring

You can further restrict the mangle rules via an IP range or an address list if possible, so this will only apply to clients and AirPlay devices. I’ll caveat that I think this is all it came down to once the VLANs were sorted. It’s been a while though, so I hopefully didn’t forget something.