,
,
,
If you search for “multiple VLANs on Synology,” you will find a lot of discussions that target DSM 5 and DSM 6. Many of those approaches either no longer apply, or they become fragile once you introduce DSM 7, Virtual Machine Manager, and Open vSwitch. DSM 7 can still be a very capable platform, but its networking model is opinionated and heavily driven by what the GUI exposes.
This series is written for technical readers who are comfortable on the command line and who enjoy building home labs or small professional environments. The objective is not to shame Synology, nor to propose an “all-in Linux” replacement. The objective is to explain the constraints we ran into, the design principles we apply in real networks, and the practical implementation that lets one physical trunk carry multiple VLANs reliably for both DSM packages and virtual machines.
We have been using Synology DiskStations and RackStations since 2010, alongside other storage and virtualization platforms. Not because Synology is perfect, but because in the day-to-day reality of small organisations and technical hobbyists the balance matters: usability, stability, serviceability, power usage, and the ability to debug when something breaks.
There are several reasons we stick to Synology:
We also have grievances. Synology networking is not “proper networking” in the way a Linux network engineer would define it. Licensing and “supported hardware” policies can be frustrating. Some models have a history of power supply issues and the support experience around that has not always been impressive. None of this is secret, and none of it is unique to Synology. We still choose Synology because the overall trade-off works for our environments and our clients, and because we can operate it at a professional standard.
Another grievance is how Active Backup for Business is often marketed as a backup product. In our experience it is more accurately described as a restore convenience. If you need to restore a directory, or recover a workstation after a failure, it can be decent. But it lacks features that a “real backup system” needs for verification, comparison, and forensic restore workflows. When something goes wrong in a large dataset, you often need to answer questions such as “what changed,” “what disappeared,” and “what was altered by malware.” If your tooling cannot answer those questions without extensive manual work, it is not a complete backup system.
We run multiple Synology RackStations internally. One acts as a project file server. For that machine we also invested in new hardware: a RS1221+ with a 10GbE NIC and NVMe SSDs used as read-write cache. This machine carries the day-to-day weight of projects, documentation, and shared datasets. A practical detail that matters to many home lab builders: Synology does not officially support 64 GB RAM on various models, yet in practice you can run 64 GB reliably by replacing the stock memory and using a matched pair. Our preference is a known-good matched pair of 2 x 32 GB dual-channel, 2666 MHz, unbuffered, 1.2V ECC modules with lower thermal losses.
Another RackStation is used for storage of video footage from Axis security cameras. We explicitly do not use Surveillance Station for this; the cameras write to storage and footage is syndicated from multiple locations to a central system over VPN. The camera retention volume is not RAID. The design intent is to keep footage for a limited window (weeks), keep the storage model predictable, and accept the trade-off that this dataset is not “business-critical forever.”
The RackStation that this series is about is our new dedicated virtualisation host; a RS1822+ with the same upgrades as the other new RackStation. We moved virtual machines that were previously spread across multiple systems onto this new unit to reduce power usage and operational complexity. At the same time we rotated older RackStations into other roles and locations, and we decommissioned legacy systems that no longer made sense operationally (including a DS210j). We also kept older hardware in service where it was still valuable, but only after addressing known issues and bringing it up to a standard we are comfortable operating.
Many home lab and small business networks are built by accumulating devices: a switch here, another firewall there, and then more ports, more power supplies, more idle power draw. We try to design the opposite way: fewer devices, fewer ports, fewer always-on watts. That is one of the reasons we avoid solutions that require “five physical NICs for five VLANs” when one trunk would do the job.
Our network is segmented. We use a management VLAN, a VoIP VLAN, an IoT devices VLAN (printers, cameras, 3D printers, and similar devices), a KNX VLAN, and a workstation VLAN (computers, laptops, tablets). Multiple physical locations are connected through site-to-site VPN.
We filter on every layer where it matters, and we do it explicitly. We run multiple EdgeRouters with distinct roles: one dedicated to the internet edge, one dedicated to VPN and inter-VLAN routing, and we apply strict ingress and egress filtering there. On our servers and RackStations, we enforce a custom firewall policy via systemd that defaults to deny and only permits explicitly required traffic. This includes default-deny for egress; a capability the Synology built-in firewall does not provide as a first-class feature. On top of that we use a dedicated security gateway that controls outbound web traffic at the application layer (HTTP/HTTPS). Cameras, printers and many IoT devices have no direct internet access; they can only reach explicitly allowed destinations through that gateway.
For naming and addressing we use a convention that is deliberately self-describing. The VLAN ID is the anchor: it matches the IPv4 subnet, matches the IPv6 prefix, and is encoded into MAC address schemes for infrastructure devices. This is not done for aesthetics. It is done because debugging must be fast and unambiguous. When you look at ARP, spanning tree, neighbour discovery, or link-local traffic, you should immediately recognise what you are looking at.
We run split-horizon DNS. Our primary and secondary DNS servers are named aphex and polygon, and our security gateway is named joyrex. These are not “the only servers on the network” (we operate many other systems as well, such as rephlex, uziq, planetmu, kid, strider, tusken, filter, lfo, warp and cylob), but they are the infrastructure names that matter for name resolution, routing behaviour and controlled egress. Their IPv4 addresses follow a consistent pattern per VLAN:
| Role | Host | IPv4 (per VLAN) | IPv6 (per VLAN) | MAC (per VLAN) |
|---|---|---|---|---|
| Primary DNS | aphex | 192.168.<VLANID>.5 |
2a10:3781:2271:<VLANID>::5 |
90:09:D0:6E:D7:<VLANID> |
| Security gateway / proxy | joyrex | 192.168.<VLANID>.6 |
2a10:3781:2271:<VLANID>::6 |
08:00:27:C8:44:<VLANID> |
| Secondary DNS | polygon | 192.168.<VLANID>.7 |
2a10:3781:2271:<VLANID>::7 |
90:09:D0:72:43:<VLANID> |
IPv6 is not an afterthought. We were early adopters: we have been running IPv6 for decades and have contributed to improving IPv6 adoption in software, hardware and real networks. In our office we had IPv6 working roughly 25 years ago, including early deployments that relied on IPv6 transition mechanisms that traversed NAT before they were standardized; approaches that are now long obsolete. Today, we run router advertisements (RA) that advertise prefixes and signal DHCPv6 usage. DHCPv6 uses DUIDs. Infrastructure devices receive stable assignments (either through DHCP reservations or manual configuration) so that links going up and down do not cause address drift. Workstations receive dynamic leases in dedicated sub-ranges for IPv4 and sub-prefixes for IPv6. Both DHCP and DHCPv6 propagate the default gateway and distribute routing information that matters for VLAN and VPN reachability.
This series will not attempt to teach the basics of VLAN trunk configuration on MikroTik, Cisco, Juniper, or Ubiquiti switches. We assume the reader can configure an access port and a trunk port or can look up a vendor-specific how-to. What we will explain is how these network design decisions intersect with DSM 7, Open vSwitch, and virtual machine networking.
Without modification, DSM is not capable of expressing what we need through the GUI: multiple VLANs on one trunk that are usable not only by DSM itself but also by packages and by Virtual Machine Manager. DSM can associate a single VLAN ID with an interface in the GUI. It does not provide a clean GUI for “multiple VLAN IDs on one port,” nor for creating virtual interfaces. Manually creating extra configuration files under /etc/sysconfig/network-scripts/ the way many users did on older DSM versions also does no longer just works on newer DSM versions.
Once Virtual Machine Manager is installed, DSM requires enabling Open vSwitch. That is a reasonable default for a virtualisation host, but it also changes the playing field. The largest hurdle is not one single limitation; it is a combination:
linux-4.4.x.txz for your platform from the GPL sources published by Synology, extract the archive and search for ovs_eth or syno_ in the files under linux-4.4.x/net/openvswitch/.In other words: this is not merely “create ethX.100 and call it a day.” On DSM 7 the solution must be designed so DSM shows the interfaces as online, packages do not ignore them or misinterpret them, and VMM can attach networks to them in a predictable way.
One small but important outcome of our naming scheme is that DSM becomes clearer to operate. DSM exposes interfaces as “LAN1…LAN5” for the base NICs. We intentionally name VLAN-facing interfaces so that DSM presents them as “LAN20” for VLAN 20, “LAN30” for VLAN 30, and so on. Internally, this aligns with our maintenance and segmentation model (for example: LAN5 is our management VLAN 10, and LAN20/LAN30 map directly to VLAN 20/VLAN 30). This sounds cosmetic until you have to troubleshoot under pressure. Clear interface identity reduces mistakes, and in segmented networks mistakes can become outages.
This is a three-part series, with the option to split Part 2 or Part 3 into A/B if the material becomes too long.
Part 3 will include code and configuration that affects low-level networking. Before you implement anything like this on your own NAS, plan recovery. In our environment we keep an unfirewalled management interface ready to plug in, we maintain a clear gateway priority order, we enable DSM’s “multiple gateways” behaviour when operating multi-homed, and we keep console access as a last resort. We also do not auto-apply patches on DSM upgrades; we do manual merges and we track upstream changes using vendor branches and tags in CVS. This keeps the system maintainable as DSM evolves.
If this series makes you uncomfortable, that is not a failure. The point is to make the trade-offs explicit and to show a path that is stable, energy-efficient, and operationally sane for people who want multiple VLANs on one Synology trunk without giving up VMM.
Next: Multi-VLAN Trunking on Synology DSM 7 - Network design deep dive Part A
Copyright © 2026, ASK-Solutions
