[UniFi] Advanced Setup | VLAN Creation guide

UniFi setup is often referred to as one of the best option for “pro” consumer (Prosumer) network. In typical home consumer setup, one is unlikely to hear a term “VLAN”. On the contrary, those who show interest in equipment like UniFi is likely inevitably heard the term VLAN at least somewhere. This is a step by step guide for basic VLAN creations in UniFi controller version 6.

In this article you will learn:

What is VLAN?

For those of you unfamiliar with Virtual Local Area Network (VLAN) concept, think it as a way to separate network without actually having separate hardwares (switches). It is similar in concept to creating multiple Wi-Fi network on a single access point. While separate SSID for Wi-Fi network (WLAN) are limited to WiFi for network isolation, VLAN applies at the level of LAN i.e. allows even wired devices to be separated into different networks.

In general, people utilize VLANs for following two primary reasons:

  1. Security

Restricting interVLAN traffic provides security benefit. For example, IoT devices may be a target source of malicious access to your network (ref), which in turn can be door to rest of your network. By separating IoT devices to their own network, even if IoT devices get hacked, there is still another layer of security.

2. Performance

Within a network, there is a process called “broadcasting”. In a nutshell, sometimes devices send data to all devices within the network. So having too many devices within a network can affect overall performance to all devices within the network (ref).

Here is my personal test results evaluating potential benefit of VLANs from performance perspective.

Main LAN is UniFi default LAN. Main WiFi is something I’ve been using ever since I got UniFi setup with single smart SSID i.e. 2.4 & 5 GHz combined. HP stands for High Performance, which are newly created VLAN and WiFi where only limited numbers of clients are connected.

The above results show independent of WiFi SSID, use of Main LAN resulted in speed degradation on 10G NAS pathway. To confirm this is not just single incidence by chance, I have performed another test following day.

This time I have added device loads on LAN and WLAN. Once again, we again see speed degradation with Main LAN via 10G pathway. This time, I have run this test twice, which confirmed consistent result.

I have done the third test where I used different access point to confirm it is not access point specific issue.

Here Main LAN again have throughput reduction both 10G down and 1G up.

Following instruction below, I have created IoT VLAN and started to migrate IoT devices to the VLAN. As of now, I have shifted about 13 devices to the IoT VLAN. Although this is ~20% LAN load reduction, I wanted to see how this would affect throughput and therefore run third test.

Here it looks great gain on the speed. However, honestly I can’t say for sure if the speed gain here is truly due to LAN load reduction because all numbers have shown gain even compared to original HP VLAN speed test, this HP VLAN is faster. Since the last test, I have rebooted my UDM Pro once so that is most likely impacting here.

Nonetheless, these tests consistently demonstrates potential of performance gain of VLANs by limiting number of connected devices.

Now if you are convinced and want to give a try making VLAN on your own, keep reading here is a step by step guide.

How to create new VLAN

Settings > Networks > Add a New Network

Name: Here you can specify name of VLAN e.g. I call IoT VLAN, Guest VLAN etc.

Content Filtering

VLAN provides several network customization. One of the option is content filtering. This is one way to restrict what type of webpage client device(s) in the network can access to.

Advanced

If you expand Advanced section, you will see a screen below. This is where you specify detail settings of the VLAN.

For the minimum setting/configuration, you can leave all default without changing anything or just specify two following fields:

  • VLAN ID
  • Auto Scale Network “On”

VLAN ID: You can pick pretty much any number you want including four digits numbers or just leave default, automatically selected ID. In general, you won’t be using this number directly because within controller you’d refer VLAN using its “name” rather than ID.

*However, if you have obsessive compulsive trait, matching subnet mask/IP address list and VLAN ID may be something you care. In which case, you have to do this manually as VLAN ID and subnet mask won’t be matched automatically by UniFi network controller.

Auto Scale Network: This is a new added feature that takes away couple additional manual settings.

Auto Scale Network

feature automatically adjusts subnet size and DHCP range with avoiding network collision.

UniFi Network Controller 6.0.20

Manually selecting Gateway IP and DHCP Range

My recommendation is just have Auto Scale Network “on” and skip this step all together.

However, if you have a reason to then turn Auto Scale Network off and then you need to set following two parameters:

  • Gateway IP/Subnet
  • DHCP Range

These two parameters are specifying what IP addresses are used when client device(s) are connected to the VLAN network. Auto Scale Network essentially fill these automatically.

For consistency, I like to keep the VLAN ID and network IPs in sync. IP addresses have some specific rules (ref). In a big picture, for Gateway IP/subnet value of 192.169.X.1/24, think of as X is only your variable i.e. keep rest of the numbers unchanged. Since I chose VLAN ID of 10, I use 192.168.10.1/24. If VLAN ID was 2, I would have used 192.168.2.1/24.

DHCP Range need to match Gateway IP/Subnet. In fact, after you change Gateway IP/Subnet, you can click Auto-Configure under DHCP Range section (not Gateway IP/Subnet section). This will automatically adjust Start and Stop IPs to match as 192.168.X.6 and 192.168.X.254.

Types of VLANs

In general, I consider 3 main types of VLAN configurations based on the interVLAN traffic rule.

  • Bi-directional, open access VLAN
  • Isolated VLAN
  • Oneway access VLAN

Open VLAN

  • Access from other VLAN: Yes
  • Access to other VLAN: Yes

This is a default VLAN setup when you create a new VLAN using UniFi controller. When a new VLAN is created, it can access other open VLAN and itself can be accessed by other VLAN.

In my case, Main LAN is a default LAN that UniFi have had from the start. Jnet LAN is a new VLAN I created where I put limited number of devices to minimize internal traffic within the VLAN along with using own DNS.

All I did here was basically created a new VLAN without any customization on Firewall rule as UniFi automatically add Open InterVLAN entries.

Isolated VLAN

  • Access from other VLAN: No
  • Access to other VLAN: No

This is an option where there is no inter-VLAN traffic allowed. The typical use case here is Guest VLAN. The key here is use Device Isolation option under Advanced option when creating a new VLAN.

Turn Device Isolation On.

Turning this option “on” will ensure Guest Network connected devices have no access to your other networks.

What’s New in 6.0?

[…]

Add new Device Isolation (creates guest network if turned on) and Internet Access (blocks WAN access if turned off) toggles.

UniFi Network Controller 6.0.20

Oneway VLAN

Once you created a VLAN, one way VLAN will need Firewall rule setting.

General steps are as followings:

  1. Create “allow established/related session rule”
  2. Create an interVLAN block rule (source to destination)
  3. Ensure to put “allow established/related session rule” top on the LAN-In list
Settings > Security > Internet Threat Management > Firewall > LAN

Allow established/related session rule

Click create New Rule

Type: LAN In

Description: Technically, you can name in anyway you like but I kept naming used on UniFi official tutorial i.e. “Allow established/related sessions”.

Enabled: Yes

Rule Applied: Before

Action: Accept

IPv4 Protocol: All

Now scroll down and expand advanced.

Here you want to turn on Match State Established and Match State Related.

This step makes InterVLAN blocking rules into explicit uni-directional. If I skip this step and create the Firewall blocking rule in next step, even though it looks source to destination (unidirectional firewall), the block will be bi-directional.

InterVLAN block

In this step, we are creating a rule that block main LAN access from IoT VLAN.

Again, click create new rule.

Type: LAN In

Description: As you build more rules, these description becomes important to ensure what the rule specifically does. In this case, I want to make sure IoT VLAN cannot access my main LAN (LAN). So I named “Reject IoT VLAN to LAN.”

Enabled: Yes

Rule Applied: Before

Action: Reject or Drop. Both option will block the traffic, but reject will send back blocked packets to source; whereas, drop won’t.

IPv4 Protocol: All

Now expand source and destination.

Source type here are Network. Source is IoT LAN and destination is LAN. This appears clear, but if we did not create Allow established/related sessions, this rule alone will blocks both direction i.e. IoT LAN to LAN but also LAN to IoT LAN.

Firewall Rule Order

The firewall rule order is important here. If you follow this guide, “Allow established/related sessions” rule should be on the top in LAN section. If this was not the case, you can drag and drop to move the rule to the top. If it was not on top, bidirectional block will happen.

This is my final VLAN setup.

For above, I created IoT LAN and Jnet LAN. Then I have created one way block between IoT LAN and Main LAN as well as Jnet LAN.

Wi-Fi Setup

Once you have VLAN setup, many of them if not all might want to have corresponding WLAN/WiFi SSID creation. This is no different from basic WiFi creation except you choose VLAN.

Setting > WiFi > Add New WiFi Network

As you can see in an above example, I am creating IoTNet. Key here is I have selected IoT LAN (VLAN) under Network section. I typically choose Both WiFi Band for convenience and rarely encountered an issue. However, with new IoT network creation I have decided to migrate some of my IoTs (of course) to the network. One of the devices are Nest Protect. Five out of six connected ok with “Both” setting; however, one kept failing no matter what I have tried. So I ended up changing to WiFi Band 2.4 GHz only. Immediately, the connection worked. Although my Amazon echo devices as well as Network printers can connect at 5 GHz, I’ve decided to just keep 2.4 GHz only as these devices should not require high bandwidth and rather save that for other demanding devices.

VLAN Testing

The final step is to test all is working as intended.

Following testings should be done here.

  1. Ping test i.e. is a device A reachable by device B?
  2. Internet connection available?
  3. Speed test

Ping test

The easiest way to do this is open a terminal/command on your desktop. Then type in command “ping [Target Device IP address].”

Let’s take a look at my case as an example.

On above setup, Main LAN and Jnet LAN should be bidirectional. So I can ping from Main LAN to Jnet LAN device as well as Jnet LAN device to Main LAN device.

On the contrary, IoT LAN is unidirectional. So from IoT LAN, I cannot ping to devices connected Main or Jnet LAN. Specifically, I get “reject error” message as that’s how I set my IoT LAN firewall rule. However, I can still ping from Main and Jnet LAN to IoT LAN.

Lastly, Guest LAN connected device have no access to any of my network, nor I can ping to my Guest Network connected devices.

Internet Connection

Another test is make sure each VLANs that you intended to have internet access do actually have such access. The easiest here is just open browser and check to see if a device on specific VLAN can surf the internet.

Speed test

If you put bandwidth restriction rule such as on guest network VLAN, this should be properly reflected. The best test tool here is iPerf for local speed testing.

Otherwise, you can use internet speed tests site, but just be aware they are can be more variable so you may need to try couple different sites at different time of day if desired number is not reached.

Beyond basic VLAN ~ To the Pro Setups ~

I won’t be covering in this article but VLAN setups have much more depth and potential for customizations. I consider those are beyond advanced user setup i.e. I call Pro setups. I am certainly not at the level myself yet. Some of the things to consider for the potential are:

  • Device selective InterVLAN traffic e.g. only allow Sonos on IoT to communicate bidirectionally
  • Port selective InterVLAN traffic e.g. only allow Sono’s requiring Ports to be opened between IoT and main LAN
  • Set default to isolated all VLANs with explicit interVLAN connection rule designs i.e. reverse of UniFi open default.

Let’s take a look at three specific situations I myself is currently facing that I still feel suboptimal.

B&W Formation WiFi speaker is placed on the IoT VLAN. With above setup, I can stream music to the speaker from my iPhone on Main LAN without an issue.

However, it fails to work properly with Roon, which is a local music streaming server located on my Main LAN. This is due to lack of access from IoT LAN to Main LAN. One can imagine the first situation is simply iPhone sends a streaming initiation command to B&W Formation Wedge, and B&W Formation Wedge connects to Amazon music across internet and get streaming. Whereas, iPhone send Roon a command to stream music and Roon then detects a compatible speaker on its list then start streaming. However, as a part it needs to be able to read information on the speaker e.g. what’s being played etc. So it needs a bidirectional access.

Second example is Amazon Echos & Sonos for amazon announcement functionality. I have set my Sonos into Alexa voice control mode. So when all devices are on the same network i.e. main LAN, “Alexa, announce […]” command will play the announcement across all speakers from any of the Echo or Sonos speaker. But now I have moved all Amazon Echo devices to IoT VLAN while keeping Sonos on Main LAN (for the reason in situation one, I need Roon access with Sonos). With this new setup, announcement from Sonos on Main LAN will work as intended i.e. all Sonos and Echoes will play the announcement. However, if I initiate announcement on Echo side, it will only play on other Echos but not on any of Sonos. This is exactly how current VLAN setup should work as it is one directional.

The third situation is a bit more interesting one. I have placed my Epson WiFi capable printers on IoT VLA. I can print from main LAN without an issue, which is as planned. To my surprise, I can actually initiate scanner function from main LAN and get full scan. However, when I check the printer selection from iPhone, I don’t see residual ink level on the printer if the iPhone is connected to main LAN, but if I connect my iPhone on the IOT VLAN, it will show up. So there is certainly some functionality (not important one for me) is blocked.

All three cases mentioned above are related to one way VLAN setup. One can potentially try opening up specific ports for Sonos/B&W Formation or perhaps assign fixed IP to certain device and allow bidirectional access only for the device etc. Basically, there are lot of potential here and at this time, I do not have enough experience to say which is the best practice.

Reference

6 Comments

  1. When I added a Reject rule as in your example, it went to the the top and it would not let me drag it down. I had to change the setting in the reject rule to “After predefined rules” instead of the before as in your example. I am new to this and may have this all wrong. I really appreciate this example detail, the retail router folks that are getting the UDM need this.

    • I wonder if it is something to do with browser. I use Safari for all these. When you choose after predefined rules, I believe all other predefined rules takes place before rejection. In which case, I worry you may not get any block at all. Have you try ping test and see if it appropriately blocking one way?

      • I see. I only have the two default rules in this order, Allow established… and Drop invalid state. Changing After/Before predefined rules puts the new reject rule before or after these two I have as you would expect and I cannot drag it anywhere. Above you say: “Allow established/related sessions” rule should be on the top. So shouldn’t I say Reject rule goes after, not before? Or are the two rules I have not the predefined rules and before/after are concerned with something else? Thanks for you help.

        • The order of two rules are absolute from what I gathered. If I switch order of two rules we created, I end up blocking full connection i.e. Reject looks like happen no matter what. If two of the created goes below other (automatically created) rules, I am afraid that can also potentially screw by allowing all traffic (not real one way).

          One thing, you must make sure you are on LAN tab to drag/drop rule. But if this still does not work, you can delete two rules and create again based on the order listed on my tutorial but for some strange reason that does not work, try delete again and now do in different order. Basically, if you do BEFORE or AFTER it will be based on what’s already been listed.

          But honestly, I wonder you may not be on LAN tab.

          • MugenMuso, you are correct. I kept looking for the “type” field as in your example when making this rule but could not find it. Seems it has been moved to an outer tab. I had entered rule creation while on the default “WAN IN” tab. I should have been on the “LAN IN” tab. I am sorry for the confusion. You can delete this thread if you choose; it was the only way I knew to contact you. If you leave it here is there any way to change my name to Red Lewis, I actually thought I was on the Unify site and had to use my real name. Thank you very much. I really have enjoyed your articles.

          • Haha. No worries and I actually feel flattered if you thought this is official Unify site. 🙂

            I have changed your ID. If you want me to completely delete all threads I can do so as well. But I thought perhaps there may be some out there who finds this discussion useful.

Comments are closed.