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.