,
,
,
In the previous article in this series, Multi-VLAN Trunking on Synology DSM 7 - Background and philosophy, we explained why this series exists and why we still use Synology despite its networking limitations. This article (Part A) is the design deep dive: the network model that makes the implementation predictable and maintainable, and the operational “gotchas” that can make a multi-VLAN Synology behave like it is haunted.
This is not a vendor-specific tutorial on how to configure VLAN trunks on a MikroTik, Cisco, Juniper, or Ubiquiti switch. We assume you already know how to create an access port and a trunk port (or you can look up a model-specific guide). What we will do is explain the design decisions that reduce complexity and prevent common failure modes when DSM, packages, VMM, IPv6, and split-horizon DNS all meet in the same environment.
Want to skip ahead? If you are mainly here for the practical implementation, you can jump ahead to the next installment: Multi-VLAN Trunking on Synology DSM 7 - DSM 7.2.2 implementation. The network layout described in this article is our production design and it makes the resulting setup easier to reason about, but it is not a requirement for the core modification: the approach in Part 3 is broadly applicable to anyone who wants multiple VLANs on a single NIC under DSM 7.
Most home labs and small professional networks start simple and grow organically. They rarely begin with VLANs. They begin with a flat network, an unmanaged switch, and a consumer “router” that is really a bundle of devices in one box (NAT, firewall, switch, Wi-Fi access point) and not particularly good at any of them once the network becomes more demanding.
The first real “segmentation” often happens after something breaks: a test rig takes down the network, a misbehaving device starts flooding traffic, or a change needs to be validated without risking the kid being able to watch telly. The quick fix is usually physical separation: buy another switch, add a second access point, or even add a second router to build a separate test network, a gaming network, or a lab corner. That works—until it doesn’t: ports fill up, switches multiply, unlabeled cables everywhere, power usage grows, and the network becomes harder to reason about. The jump to managed switches and VLANs often follows out of necessity, and sometimes out of curiosity.
We have seen this pattern for about 25 years: at clients, in community setups, and in our own environments. We have helped untangle it many times, and we also grew into it ourselves. In the early 90s we ran two dial-up bulletin board systems (BBSes) and a FidoNet node: users connected by modem to a menu-driven system to read and post messages, exchange files, and send mail.
In that era, “internet access” did not automatically imply “browsing websites.” For many people it meant reaching specific network services: e-mail, Usenet, file transfer, or navigating structured information systems such as Gopher. Even on direct connections inside universities or corporate networks, the experience was often service-oriented and mediated by gateways, catalogs, and client applications—not by a graphical browser. As the World Wide Web emerged and Mosaic made HTML accessible to a much wider audience, the centre of gravity shifted and those service gateways quickly evolved into full internet access in the modern sense.
That box ran DrDOS first, later Windows NT 3.5, briefly NT 4, and OS/2 Warp, before we moved it to Red Hat Linux. Around 1998 the platform was upgraded to a Pentium 233MMX, deliberately clocked down (to reduce energy consumption). The details are dated, but the lesson is not: before you reach for VLANs, most people (including us) solve real problems by adding hardware and building “separate” networks. VLANs and policy routing are what you adopt once you want to keep the flexibility, while eliminating the sprawl.
Our design goal is the opposite: consolidate where it is safe, and make the result deterministic. A single 10GbE trunk from the NAS to a managed switch can carry multiple VLANs cleanly and with high bandwidth. It also avoids consuming five physical ports on the NAS and five switch ports on the other side. For an always-on environment, that translates into fewer devices and lower energy usage.
There is an important nuance: “a trunk” is not a design on its own. The trunk is only useful if the host stack (DSM + packages + VMM + Linux) exposes VLAN networks in a stable and debuggable manner. The rest of this article is about the design choices that make that true.
We segment by function. In our environment that includes:
Multiple physical locations are connected through site-to-site VPN links (IPsec in our case). The precise VLAN numbers are less important than the principle: segmentation is not only about security; it is also about stability and observability. When something breaks, you want the blast radius to be small and the symptoms to be attributable.
Segmentation is only meaningful if enforcement exists where it matters. We enforce policy on multiple layers:
The practical benefit of this approach is that it becomes much harder for “accidental connectivity” to exist. If something suddenly talks to the internet, it is either explicitly permitted or it is a configuration bug you can detect and correct.
Complex networks fail in predictable ways when identity is ambiguous, even if the symptoms feel random at the point of troubleshooting. We therefore use a self-describing convention where the VLAN ID is the anchor for multiple layers:
192.168.<VLANID>.0/24).2a10:3781:2271:<VLANID>::/64).90:09:D0:6E:D7:<VLANID>).This is not aesthetics. It is operational engineering: the same identifier appears in L2, L3, and naming conventions, so it is hard to “accidentally” misinterpret what you are looking at.
We run split-horizon DNS. That means the DNS “view” differs by network context: per VLAN, but also per site-to-site VPN and for external/public resolution. An internal hostname may resolve to a different address depending on where you query from. This is normal and desirable in segmented environments, but it introduces a common failure mode: if a host uses the wrong resolver for its interface/VLAN (or VPN context), it can resolve an internal name to an address that belongs to a different segment.
Our core infrastructure names are:
| 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> |
Operational rule: each interface must use the correct DNS servers for its VLAN view. If not, you get extremely confusing behaviour: a hostname resolves “correctly” but to the wrong VLAN, and the symptoms look like firewall issues or routing issues when the real cause is name resolution.
Previous: Multi-VLAN Trunking on Synology DSM 7 - Background and philosophy
Next: Multi-VLAN Trunking on Synology DSM 7 - Network design deep dive Part B
Copyright © 2026, ASK-Solutions
