Pages

Wednesday, October 2, 2013

Provisioning Synology NAS to Support Multiple VLANs/Subnets

A few weeks ago, I decided to purchase the Synology DS1513+ as my home office NAS solution. Even before receiving the gear, I was sketching out how I would integrate the solution with my existing home network. I had a clear need to support multiple subnets/VLANs. Synology is supposed to support 802.1q vlan tagging but I found out that the implementation is somewhat limited and I had to come up with a workaround. I was able to gracefully solve the problem and I figured I would share the information with others. I didn't invent either solution presented in this article. I pieced it together by putting in a few hours of research.I found a lot of inspiration from the Synology forums: http://forum.synology.com/enu/

Background

I have two distinct operating environments in my home office. I have a "production" network and a "lab" network. The production network hosts desktops, laptops, and other devices my wife and I use for work. The lab network has Cisco phones, routers, switches, etc. I also host numerous VMs on a Cisco UCS and a Dell PowerEdge platform. The main reason I decided to procure a NAS solution for the home office is because I previously had what could be called "a fully distributed and mutually oblivious" storage solution. IOW, I had crap everywhere! I had several requirements but the most important one (at the time, anyway) was to provide a single, centralized storage solution that could be used by all of the devices in my home. There is a little bit of a curve ball here. My "prod" and "lab" environments are completely segregated from each other and inter-communication is restricted. I have a firewall in front of "prod" and an ISR with FW rules in front of "lab". In between is what amounts to a DMZ.I don't want to configure custom FW rules nor do I want to traverse unnecessary devices to access my NAS (i.e. lowest common denominator and all). What I need is a NAS solution that can have a physical or logical leg in each environment.When I reviewed specs, I saw that Synology support VLAN tagging. Groovy, that sounds perfect. However, I quickly learned that my idea of VLAN tagging and Synology's differed. So, I hit a barrier. Fortunately, I found two solutions to my problem. Neither are native features exposed through the Disk Station Manager (DSM) interface. If they were then there would be no reason to write this blog.

Option 1: VLAN Tagging

Wait? You said that VLAN tagging wasn't supported?Correct. I discovered that you can provision the DSM to tag a VLAN. However, it will only tag one VLAN. So, the option is: tag with this 1 VLAN or don't tag at all. Well, that doesn't really help me out. Not to mention, the feature is pretty useless in its current form.After some digging, I found several references to a method that people have said would allow the Synology to work with multiple tagged VLANs. Of course, this method is not supported by Synology and is not configurable via the DSM UI. You need to make the necessary configurations using root via the CLI. Now, I decided not to go this path but I am providing the information I collected for those who want to pursue this option.NOTE: This method is not supported by Synology and I am not offering any guarantees or warranty. In other words, proceed at your own risk. Information on this process came from the Synology forum and this blog entry: Multiple VLANs on Synology NAS

Enabling Terminal Access

To create/edit the files needed to support this method, you need to have terminal access to the Synology box. You can enable terminal access from the Control Panel. First, HTTP(s) to your NAS and logon. Then click on the Control Panel icon.

From Control Panel, choose Terminal under "Network Services". You will likely have two terminal service options: Enable Telnet and Enable SSH. Choose what works in your environment. I always opt for SSH when given the choice.

Access the Terminal

To do what needs to be done here, you need to telnet/ssh to your NAS. You will need to login as the root user. This user account will have the same password as the admin account that you can access via the web UI.Once you authenticate to the NAS, you need to go to cd /etc/sysconfig/network-scripts/ and edit the following files:FILE: ifcfg-bond0

As previously noted, I decided to not go down this path. This method is somewhat cumbersome and there is not guarantee that it would survive an upgrade. Also, based on what I read, people found that they would have to reconfigure the workaround after a system restart.

Option Two: Static RoutingThe second option I found involves setting up static routing on the Synology NAS. This is the method I used in my environment and it is working like a champ. The trick here is that there is no way to add alternate routes via the DSM GUI. You can only specify the default gateway.No worries, you can work around this limitation using the CLI.PreparationAs with the previous method, we need to SSH to the Synology device to customize how packets are routed. Start with the "Enabling Terminal Access" and the "Access the Terminal" procedures discussed previously.

Configuration

You can use the procedures herein on any combination of interfaces. I created two link bundles. Bond0 was assigned Gig interface 1 and 2. Bond1 was assigned Gig interface 3 and 4. My intention was to place Bond0 in my production network and Bond1 in my lab network. In DSM, I configured the default gateway to be the router IP address for my production network (so, Bond0's subnet). All that remains is to program some static routes on the NAS itself:

In the above example, I add two static routes to the rc.local file. These routes don't go active until you reboot. So, I just executed the same commands in the BusyBox shell after saving the file. That's about it.

ConclusionFor the time being, I have opted for the second option (static routes). It works fine for my immediate needs. I have been able to run VMs, mount ISO installs, etc. on the lab network, while doing time machine backups and downloading installation files on the production network. The performance is fine.

9 comments:

Yes, I have run CUCM VMs on the NAS. I run my ELM instance from the NAS today and I had a bunch of VMs for my IE lab that I moved off of my UCS DAS and migrated to the NAS. I loaded them to see if they would boot but haven't used them for much.

I wonder what is wrong with the world when one can move about his whole life without encountering the language you use. I'm afraid networks will forever escape me and this somewhat saddens me. I own a Syn 1813+ NAS, it does whatever I require of it fine but I still haven't a clue what you're talking about.

lan1 behind router1 is used for public services (www server,dns,etc)lan2 behind router2 is used by wife/kids.

the diskstation has 2 nics; into lan1 and lan2

so far the same as you.

the diskstation runs webservices (mail, http, ftp etc..) and dns

to make sure my domain name is always resolved to the right ip address, on local lan or on internet, i need to run split-dns, using 'views' in the dns server.

now, i have some ip cams that mess up my 1rst router, and my isp doesn't give a crap that i have to reboot the thing 2-3 times a day.

my idea was to put the cams in a 3rd VLAN/subnet, but the vlan-implementation by synology is useless for this. the only way around it seems to be: routing through a layer 3 switch i suppose. now, i got me a switch (netgear gs110tp) that supports vlan trunking and tagging, and some ip/mac based blocking, but no routing between vlans.

not sure why i'm replying this to our message, but your idea using static routing got me curious if maybe you had some other sublime ideas on that?

hi, very informative post. I am looking to something almost identical, but I am still missing something that is preventing it actually working. Any chance I could run the setup by you? If so I'd appreciate it. I have a ds916+, and cisco sg-300 in layer 3 mode. Thanks.

Welcome!

My name is William Bell (CCIE #38914) and I am a Senior Consultant and Practice Lead with Chesapeake NetCraftsmen. My area of expertise is Cisco Unified Communications (UC) and Collaboration. I have worked with UC and Collaboration solutions and products for over 10 years.

My objective with this blog is to share my independent interpretation on designing, deploying, and maintaining UC and Collaboration solutions.

Thank you for visiting the site. Please, keep your hands and arms inside the vehicle at all times and enjoy the ride.