UniFi Network Update Part 2: VLANs, WiFi Partitioning, and Advanced Features
February 10, 2021Today on the hook up it’s time for part 2 of my Ultimate Secure Smart Home Network series. In Part 1 I walked you through hardware selection using UniFi equipment and in today’s video I’m going to show you how to get your network setup using cybersecurity best practices including VLANs, Firewall Rules, Port Security, Intrusion Prevention, and VPNs.
Before we get started, I think it is important to mention that convenience and security are opposing ideals, whether you’re talking about physical security or cyber security, the outcome is the same: Most increases in security will also come with a decrease in convenience. Leaving your doors unlocked saves you time and effort when coming home, but at the cost of your home’s security and your personal peace of mind, and the same goes for your network. The goal is always to minimize this tradeoff using technology but whether it’s increased setup time, decreased network speed, or even loss of some functionality, you’ll need to decide where you want your network to fall on the continuum of convenience vs security. I’m going to show you my setup, which I would put closer to the secure side than the convenient side, but you can pick and choose the parts that you think are important if my setup too conservative for you.
In the internet of things device communication can sometimes be complicated, but for the most part the IoT devices can be divided into four main categories: Devices that need to communicate with a cloud service outside of your network, devices that only communicate inside your local network, devices that need to talk to a cloud service and devices on your local network, and last, devices that don’t need outbound communication at all, and should only speak when spoken to.
Take my sense energy monitor for example: It collects data about my electrical usage and sends that data to the cloud. When I open up the app on my phone, I’m not actually talking to the device in my house, I’m communicating with the cloud as a middle man. Similarly, when I use that energy data in my home automation platform, the energy monitor doesn’t talk to the hub, despite being 20 feet away from each other, they instead use the cloud as an intermediate.
This means that the sense falls into the IoT device class that should be allowed to communicate with the internet, but blocked from all local communication. My Amazon echo devices are similar in that they are communicating with the amazon cloud for 99% of what they do, but they do talk to each other on the network in order to synchronize multi room audio, and they need to talk to my home assistant server to process alexa local devices in node-red. So even though they are in the IoT device class, I’ll also need to set up a custom rule to allow them to communicate with one another.
As a general rule of thumb, I try to avoid cloud devices and choose local control whenever possible, but anything that utilizes a service, be it Netflix, Disney plus, or even just the amazon cloud unfortunately can’t operate 100% locally.
That brings me to the next device class, which is for all the locally controlled devices on my network. This includes all of my smart switches that run the custom Tasmota firmware or use shelly’s local control options. These devices don’t need any internet access and only need to communicate with my home automation server. I call these devices my network of things, or NoT because they only need local communication. Similar to the IoT network, they don’t really need to communicate with each other either, so I can block all of their traffic except for communication over specific ports with my home automation server. If you’re not sure whether a device should be on your IoT or NoT, unplug your internet connection and see if it still works, if not, it’s an IoT device.
Next are devices that should be able to access everything on the network. Cybersecurity best practice actually says that this device class shouldn’t exist and that if a device needs this kind of access it should be temporarily elevated to higher privileges to complete a task and then returned to a lower privilege state. However, in an effort to maximize convenience I keep all of my family’s phones, computers, and tablets on this main untagged VLAN, but a little later we’ll talk about how security features like intrusion prevention systems may help mitigate any possible vulnerabilities on these devices.
Another questionable decision that I’ve made on my network for practical reasons is to put all of my completely untrusted devices onto my main untagged VLAN. Here I’m specifically talking about security cameras, which are ironically one of the most unsecure devices from a cybersecurity standpoint. The way that a security cameras work is that each one has a little video server running on the camera itself and if a device like an NVR wants to view that feed it contacts the camera and initiates the stream. There’s no reason for a device outside my network to initiate a camera stream, and no reason for a camera itself to initiate a connection with another device so I’ll block 100% of their outbound traffic via firewall rules.
The reason for putting them on the same untagged VLAN as my server is that it reduces the strain on the router significantly to not have to pass 11 4K video streams across VLANs from each camera to the NVR. Just having them on the untagged VLAN doesn’t represent a security flaw since they have a corresponding firewall rule, but the real problem is that this represents poor network port security. An easy way to get full unlimited access to my network would be to tear one of my security cameras off the wall, unplug the ethernet cable and plug it in to YOUR device. Because the security camera group is defined by their IP addresses, which are ultimately assigned based on their MAC address, a new device will pull a fresh IP address and therefore will not be bound by the camera firewall rule. Thankfully, there’s more than one way to secure a network, so we will deal with this issue using port restrictions later on.
Now that we’ve talked through the network architecture, let’s see how to actually implement these policies in the new UniFi 6.0 controller interface and dashboard.
The first thing I did on my UniFi Dream Machine Pro was set up a local admin account and disable cloud access. To do this click on users from the UDM local portal, then either make yourself a new super admin local user, or add local credentials to your cloud account. If you want you can also completely disable cloud access to your UniFi controller by going to settings, then click advanced, and toggle the “Remote Access” switch to off.
It’s unfortunately still not possible to do initial activation and setup of UDM Pro without a ubiquiti account, but at least you can move back to local control once it’s installed. There is currently a significant amount of customer backlash from this issue and pushing the same limitations to the cloud key gen2, so maybe it will change in the near future.
After you’ve logged in with your new local credentials, click the network button and if you’re on Controller version 6.0 your dashboard will look something like this. If not, you can go to settings, user interface, and then toggle the new dashboard and new settings switches. You can try out new clients as well, but I personally don’t like it because it’s missing important information like which access point each device is connected to. For the time being you can also easily toggle between new and old settings if you can’t find the setting you need in the new menus.
The first thing that we need to setup are our networks, and we are going to start with 3 different virtual networks within our single physical network. To set these up go to networks and click on add new network.
My first network will be my IoT network, and after adding the name you’ll see that all the other important settings are now in the advanced tab. My IoT network is going to be assigned to VLAN 20 and isn’t associated with a domain name. The next option on the list is for device isolation, which sounds great and like exactly what we want for the IoT network, however, I’m not going to use it, because even though this likely turns on some internal firewall rule, that firewall rule doesn’t show up in the interface anywhere, so it’s impossible to allow exceptions properly since we don’t know whether that rule is being applied at the beginning or end of the chain.
The next option is IGMP snooping, which is a feature that specifically applies to multicast communications. To understand the difference between the different types of network traffic lets look at Twitter. On twitter you can send private message to a single other twitter user and they can respond on that direct channel, in networking we would call this unicast. Another way that you can interact with people is you can follow them, and then they can send out special messages that will go to all of their followers, they aren’t necessarily talking directly to you, but you’ve indicated that you may be interested in what they are talking about. In networking this is called multicast, and IGMP is the protocol that it used to figure out who is following who, so that when a computer sends out a multicast message it gets delivered to only the interested parties. There’s also another type of communication called broadcast that’s more like the announcements that Twitter makes that you don’t have any option but to look at, but we’re interested in here is Multicast.
As I said, IGMP is the method that your devices use to indicate that they want to receive another device’s multicasts, the problem is that by design multicast only works within the same network, and since we have 3 separate virtual networks, the devices on one VLAN have no way to follow the devices on another VLAN. However, if we enable IGMP snooping the router looks at what each device is interested in, and then sends the same type of traffic from other VLANs in addition to the local VLAN traffic.
HOWEVER, there is a problem, if the VLAN you are assigned to doesn’t have any of the multicast traffic you are interested in, the router will never know that you want to see it. This is getting confusing, let me give you an example: All of my chromecast devices are on my IoT network, they need to be able to talk to the internet to stream all their services, but I also want to be able to cast from my computer to the chromecast. When I click the cast button on my computer it will generate a list of available devices based on multicast messages that the chromecast sends out basically saying “Hey, I’m an available casting target”. If I put a chromecast device on the same VLAN as my computer, then my computer would join that IGMP group and would hear messages from all the chromecasts on all the VLANS, but since there are no chromecasts on the same network then my computer never joined the group and IGMP snooping doesn’t know to send those messages from the IoT VLAN to my computer.
That was a REALLY long winded way of saying that if you have devices on your network that advertise their services like casting, over the air updates, voice assistant integration and lots more you may need to turn IGMP snooping off, as well as turning on the MDNS repeater, which we’ll cover later, in order to keep those services working across VLANs.
Next you’ll set up the subnet for your VLAN. I like to keep my subnet the same as my VLAN number, meaning if I put in VLAN 20, I’ll want my gateway and subnet to be 192.168.20.1/24. The /24 part at the end refers to how much of the IP address will be the same for the entire subnet, 24 means the first 24 bits are part of the address and the last 8 bits will vary based on the device, another way you’ve probably seen this is in the subnet mask, which in this case would be 255.255.255.0, meaning the first 3 8 bit numbers are part of the network address, and the last 8 bit number is part of the client address.
UniFi is doing their best to make sure their users don’t need to understand all this stuff, so they give you the option to auto calculate your subnet. They also give you the option to auto scale the size of your network as needed, which I think is really strange, and I can’t think of any reason you’d want to do this.
IP addresses need to be unique for each device on your network, and they can be assigned in a few different ways. The most common way is for a device to request an IP from your router called DHCP, and in this case your router looks at the IP addresses currently being used and assigns a free IP address from a range that you define. The second way is called a DHCP reservation, in which you tell your DHCP server, the dream machine pro in this case, that you always want to give a specific IP address to a specific device based on its MAC address. Every time that device attempts to connect to your network it will ask for an IP address like normal DHCP, but the dream machine will always give it the same address and will never give that address to another device. The third and final way is called a static IP address where the device itself to defines its own IP address, and tells the router what its address is instead of asking. Static IPs can lead to issues if they are outside of the defined subnet, or if that address is already taken by another device.
A common way to avoid these IP conflicts is to start your DHCP range, above 100, this will give you roughly 153 DHCP IP addresses and 94 static IP addresses. Personally, almost all of my devices will use DHCP, so I prefer to keep the DHCP range large and then reserve IP addresses in the router for any device that I want to use the same IP address every time it joins the network.
Again, long story short, just define your own network size and DHCP range rather than having the controller automatically expand your network.
The rest of the options will be specific to your setup. I personally specify the DNS servers that I like my devices to use so it doesn’t default to my service provider’s DNS server. I used cloudflare’s dns at 1.1.1.1 as my primary server and google’s dns at 8.8.8.8 as my secondary.
I also define my own network time protocol server since I run the Chrony addon on my home assistant server, this helps me keep NTP requests local so I can block more outbound traffic in my firewall. This does come with some inconveniences, namely that some devices don’t pay attention to the NTP server specified to them by the router, in which case you’ll need to log into those devices to change their NTP server manually.
After you’ve changed any extra settings for your specific network, go ahead and hit save and repeat that same process for your NoT network, except this time you’ll specify the VLAN as 30, and the gateway and subnet as 192.168.30.1/24. Remember if you want ALL of the multicast data from this network to be repeated on your other VLANs then you should disable IGMP snooping on this network.
Last, you’ll may want or need to change your default LAN network to use a different subnet if you already have a bunch of devices setup using that IP address. To do this just click the pencil icon to edit, and then edit the gateway and subnet addresses as needed.
UniFi has also added the ability to designate a network as a work or family network. These networks work similarly to any other network type, but will use a special domain name server. For the uninitiated, DNS is how your computer finds out the IP address of a remote server given its domain name. In these special family and work networks the dream machine uses its own DNS which sends all adult sites into something called a DNS black hole, which just makes the site show up as unresponsive. Additionally, the DNS can also redirect google and youtube traffic to their safe mode subdomain to filter explicit material and turn off comments.
This isn’t new tech, and has been relatively easy to implement in the past using popular software called piHole, but it’s a neat addition assuming they do a good job upkeeping the list of prohibited sites, which I don’t have high hopes for since the list of sites that they use for deep packet inspection hasn’t been updated in at least 10 years now.
Since I have an 8 year old I decided to give this a shot, so I set up a 4th network called family, and I’ll show you how to put wired devices onto that network later on, but unfortunately using this implementation, the only way to get wireless devices onto this content controlled network is to define a specific SSID for them.
Now that we’ve got our networks defined we need to assign them to wireless networks. The way that I’ve divided my network I know that my IoT and NoT devices are stationary and should be connecting to a specific access point on a specific frequency band. For this reason I’ve broken out my SSIDs not only into IoT and NoT, but also the area where the devices are, downstairs, upstairs, or outside. In the old UniFi controller I accomplished this with SSID overrides on each access point, but that feature has gone away, and the new method is to use WiFi groups. To make these groups you need to start configurating a wireless network, so in settings click wifi, then add wifi network and then click on advanced. Each wifi group needs to have at least one access point associated with it, but can include as many as you want. I’ll make a group for upstairs, downstairs and outside that contain only a single access point, and then there is also a group that contains all the access points for roaming devices.
For each wireless network I will use the same base name, in this case TaitIoT or TaitNoT, and then an underscore followed by the location of that device. For instance my outside NoT network is called TaitNoT_Outside and I’ll assign it specifically to the NoT network and the outside access point group. It’s also helpful to disable any unused radios for these networks, for instance, I know that my outside NoT group only contains 2.4 gigahertz devices, so there’s no reason to broadcast this SSID on the 5 gigahertz channel. Disabling unused SSIDs will help reduce interference decrease the number of beacon messages being sent out by each access point.
Next are the advanced feature toggles. If I have one main gripe with UniFi it’s that a lot of their options are vague and require a decent amount of digging just to figure out what they actually do, end even then there is sometimes no official documentation. A general rule of thumb for any advanced feature is to turn it on and see if any of your devices respond negatively, and if they do, turn it back off.
That being said, here are some basic explanations of what these features do:
Unscheduled Automatic Power Save Delivery allows devices to tell the access point that they want to save battery, and any data meant for a device in power saving mode will be stored up for a short period of time and then delivered all at once instead of a having a constant stream of data to the device. This allows the device to turn off its WiFi radio for a longer period of time without missing information or being disconnected from the network. In theory you should be able to enable this feature without any issue, but your specific device will need to support UAPSD to see any benefits, and as I said, if you enable it and you see issues in older devices you can safely turn it off.
Next is multicast enhancement, the first of the cryptic options. From what I can tell this is just a place to enable IGMPv3, which is how devices join multicast groups as we discussed before. I have multicast enhancement enabled on all of my networks and I’ve never had an issue with it. It is oddly disabled by default.
Forcing high performance devices onto the 5ghz network only means that if a device supports 5 gigahertz it only gets to use 5 gigahertz, even if the 2.4 gigahertz signal is significantly stronger, which is a bad plan because of attenuation issues with the 5 gigahertz band. I’d say the only reason to use this is if you have an open air office with lots of cubicles where every device will have direct line of sight to the access point. Keep it off for home use.
BSS transition monitors the signal strength of your devices and sends a special management frame to weak signaled devices telling them they may want to transition to a different access point. This feature should be disabled on all of the networks that are using a single access point, since even a weak signal device shouldn’t try to roam to a different access point. I do have this feature enabled for my main WiFi network that I use for phones and tablets.
Proxy ARP should be off for 99% of networks, and if you need to turn it on then you already know what it means.
Layer 2 isolation means that the access point doesn’t even check firewall rules before denying communication between devices on the same network. This is useful on a guest network, but should be off on all your other networks.
Legacy support will allow really old devices that use 802.11b to connect to your network. Remember that adding these older slower devices will increase the time that all of your devices will need to wait to talk to your access point, which will not only slow them down, but may also cause connectivity issues. Unless you have a specific very old device that you can’t live without keep legacy support off.
Last is enable fast roaming, and similarly to the BSS transition frames you want to keep this setting off for all of your networks except for the main roaming network. On my main network I only have laptops, phones and tablets which can all use fast roaming, but if you notice connectivity issues when changing locations in your house you should shut this feature off.
Under security you should have WPA-2 default, hide SSID off, and PMFs on either optional or disabled. PMFs or protected management frames mean that only authenticated devices can send frames that instruct clients to associate, disconnect, or roam. It seems crazy, but the way that WiFi was originally designed, any device can tell another device to disconnect from the network, even without knowing the wifi password. This leads to one of the most common attacks on wifi networks called a deauth attack where a single device sounds out thousands of deauthorization management frames to disconnect every device in range. This attack is a common first step to a man in the middle attack called an evil twin, a method for collecting authorization frames to analyze, or just as a denial of service type attack.
Protected management frames are great, and they will to much more secure connections in the future, but as of right now there are not enough devices that support them to be able to set this feature to required, and I’ve even had some trouble with my ESP8266 based devices when it is set to optional.
Keep your group rekey interval set to the default.
This section also allows you to allow or deny devices based on their MAC address. I had an Amazon Echo Show that I temporarily switched onto my main network to record part of a video and even after switching it back to my IoT network it would occasionally show up on my main TaitWiFi network, even though I told it to forget that network. To prevent this I added its MAC address to the deny list for my main network preventing it from joining ever again.
The last section allows you to turn off your WiFi network based on a specific time of day. I don’t find this useful for my setup, especially since UniFi integration for home assistant lets you shut off internet access for specific devices, so I don’t specify a schedule in this section.
Here’s a quick reference for setting up your WiFi network options, remember you’ll need to create a separate network for each VLAN and access point if you want to force devices onto a specific access point based on their location. Each access point can only broadcast 4 different SSIDs, so with a main, IoT, NoT and guest you will be maxed out.
The next step is the most important one for the security of your network. Firewall rules or what are sometimes called Access Control Lists or ACLs are the main system that governs whether devices should be able to communicate with each other or the outside world. Best practice in network security is a concept called Zero trust, or similarly least privilege, which basically means that you should start by blocking all traffic to every device on your network, and then only grant specific access to devices that need it, when they need it. In the UniFi controller, firewall rules are processed from the top down. That means that if traffic is specifically allowed by a rule at the top of the list, no other rules will be checked to see if they apply. Because of this I find it easiest to put specific allow rules at the top of the list, and generic deny rules at the bottom. If you’re using a firewall other than UniFi make sure yours operates the same way before blindly following this tutorial, otherwise you could lock yourself out of your network completely using too broad of deny rules.
Speaking of other firewalls, another issue when dealing with multiple vendors is knowing the built in or implicit rules. UniFi uses implicit allow for all local networks, and implicit deny for your external connection. This means that if you don’t make a firewall rule specifically denying it, all local traffic will be allowed between VLANs on your local network and similarly, if you don’t make a specific allow rule, all incoming traffic from external sources will be blocked. Different vendors will have different built in policies, like using implicit deny between VLANs, but UniFi allows all VLAN to VLAN traffic by default. You can view these built in rules in the firewall section where they show up as ghosted text and cannot be edited.
On my network I use home assistant, plex media server, amazon echo with multi room audio, chromecasts, and rokus. I’ll setup my rules based on these devices. If you use other services like Sonos for instance, you’ll need to figure out which ports they need. If you use a service that isn’t covered here and figure out a firewall rule to make it work post it as a comment down below and I will not only check it for security flaws, but I’ll favorite it so other people can use that rule if they need it.
Okay allow rules first.
A surefire way to cause issues with any device is to block it from getting the correct time. Using incorrect time can make it impossible to use encryption properly, and may cause some devices to stop working entirely. For this reason I let all of my devices have access to the network time protocol or NTP which communicates on port 123. This is an outbound communication and the response is covered by the built in “allow established and related” rule.
Click on new rule, then select LAN in, which is where your firewall is going to see this traffic originating, essentially the door into your router marked IN coming from your local area network.
Next give it a descriptive name, I’ll call mine “Allow All Local to NTP”
We want this rule to be applied before all other rules, and we want it to accept the traffic that meets this criteria.
Remember, with these are accept rules, so you should make them as specific as possible. I happen to know that the network time protocol uses UDP, so I’ll specifically only allow UDP packets. Under source type I want to use a group of IP addresses, so I’ll select address/port group and then in the IP group I’ll select “Create new group” and I’ll make a group called “All Local Addresses” which contains all of the IP addresses inside of my network, which are 192.168.86.0/24, 192.168.30.0/24, and 192.168.20.0/24, after entering all the IP addresses hit create new group and make sure it’s selected in the dropdown. This traffic will be allowed to originate from any port, but should have a destination port of 123. You can define this single port using the IP Address dropdown option, or I like to make groups for everything, so they are more descriptive. Click create new group, then name it NTP port and put in port 123.
The next rule to configure will allow my IoT devices to communicate with my home assistant server. Depending on the type of devices you have on your network, you might not need this rule at all. This rule is only necessary if the devices you use are listed as local push. If they are listed as local polling then home assistant only need to be able to communicate with them, which it can by default because it’s on the main untagged VLAN that we are giving unlimited network access to. If your device is listed as cloud polling or cloud push then the local devices do not need access to home assistant.
The broadest setup of this rule should be LAN in, applied before, accepting all, from source network IoT to destination home assistant server. I only have one home assistant server, but again, I like to make a group with just that one IP address so the firewall rule is more descriptive. To follow the concept of least privilege you can make a group of IP addresses that need local push access and instead of giving access to the entire IoT network, the fewer permissions that you give the more secure your network will be.
Remember that any time you add a device to one of these IP address based groups you should also reserve that IP for only that device using the UniFi dashboard, this not only ensures that your device will take the same IP address each time it connects to the network, but it will also prevent another device from getting that IP address, and therefore having more permissions than it should.
My next rule is to allow my NoT network to communicate with home assistant via the MQTT protocol. For this rule, you should choose LAN in, apply before, allow TCP, and for the source it should be the NoT network, and destination should be your home assistant server, and MQTT port which is 1883 for unencrypted MQTT and 8883 for encrypted MQTT. Again, you could define a more specific group within your NoT network, but all of my NoT devices use MQTT, so I don’t do that.
My amazon echo devices are on the IoT network, which means they can’t communicate with any devices locally. I’ve found that for multiroom audio to work correctly the echo devices need to be able to communicate with each other, so I’ll make a specific firewall rule called echo to echo, in the LAN in area, apply before other rules, allow all protocols, with a source of my group of Echo devices and a destination of my group of Echo devices.
Chromecast devices need some specific ports open for communication, so I’ll add a rule called allow chromecasts, which will be in LAN in, will apply before other rules and will allow all protocols with a source of my IP address based group of chromecast devices and a destination of any device on the network that I may want to be able to cast from on these 7 chromecast specific ports. On my network my casting devices happen to be all the devices on the main untagged VLAN but if you want to limit which devices can cast, you can make a smaller IP address based group for that. Also a quick note, I’ve noticed that chromecast streaming functionality is significantly increased by disabling IGMP snooping on the IoT VLAN like we discussed earlier.
My last allow rule is to give my streaming media devices access to my Plex server. For this rule I’ll choose LAN in, apply before, allow TCP and UDP with a source of an IP address based group called streaming media devices, and a destination of my plex server specifically on these 10 ports required for plex and it’s different services.
At this point, my firewall is exactly the same as when I started since all I’ve done is make allow rules, and the UniFi LAN firewall uses implicit allow, meaning all traffic was allowed anyways. So to secure my network I’m going to make broad deny rules for each network.
My IoT devices shouldn’t be able to communicate with any devices on my network, so since I already created a group called all local addresses I can make a new rule called Drop IoT from local, choose LAN in, apply AFTER other rules, drop all traffic with a source of my IoT network and a destination of my all local IP addresses group that I made earlier. If I ever want to add an additional VLAN I just need to remember to add it to this group.
My NoT Devices shouldn’t be able to communicate with any devices at all other than the MQTT allow rule that I specified before so I’ll make a rule called drop all NoT, choose LAN in, apply after and deny all traffic with a source of my NoT network and a destination of any IP address and any port.
And last I’ll make a similar deny all rule for my security camera group. Lan In, apply after, drop all traffic with source IP address based security camera group, where I’ve reserved their addresses via DHCP, and destination of any IP address and any port.
As I said before, firewall rules are read from the top down and it’s a kind sudden death scenario where the first time a packet matches the conditions of a rule then that rule is applied and no other rules are checked. So each time a packet comes through it will check to see if it is in any of the allow specific allow rules, and if not it will be denied by the generic deny rules. There is a theoretical speed increase to be had by putting the rules that apply to your most common types of traffic higher up in the list, but in practice on a home network there is no reason to stress about which allow rules are first, as long as the allows come before the denies.
Even though firewall rules are the most important tools for securing your network, there are other features available in the dream machine pro that provide additional layers of security.
The first one is called IDS or IPS. IDS stands for intrusion detection system, which IPS stands or intrusion prevention system, and they both have the same main concept, but different final outcomes. IDS and IPS basically work the same way as antivirus software on your computer, which is oddly similar to how your body’s immune system works as well. Basically when a new virus is discovered, security researchers try to pinpoint a part of that virus that it sufficiently unique to identify it without also falsely identifying non-virus files, and they call this part the virus’s signature. These signatures are added to an ever growing and constantly updated database that your antivirus program can reference as it is examining each file on the computer. If part of the file matches the signature in the database it will be flagged, quarantined, or just outright deleted depending on the preferences you set. IDS and IPS are the same in that they reference a large database of signatures related to malicious network traffic. If you have intrusion detection enabled any matches will generate an alert for you to deal with yourself, while intrusion prevention will block that traffic automatically. The likelihood of false positives, and the impact on your network if legitimate traffic is blocked will determine whether IDS or IPS is right for you, and while the dream machine pro has claims of 3.5 gigabits per second of throughput with IPS enabled, this metric is tested using very similar traffic types and real world throughput may be less.
Each category in this menu refers to a subset of signatures in that malicious traffic database, so if you want to use peer to peer software, and you’re concerned that your traffic will be blocked by IPS you can disable just that subset of malicious signatures.
UniFi hasn’t been particularly transparent about where they are pulling their signature database from, whether they are maintaining it on their own, or how often it is being updated, but I’d really like to know more about that information. I also hope they will offer the option to update signature files without completely updating the firmware of your device, because signature updates should be happening significantly more often than device updates and should be able to be done without the fear of breaking changes.
The second additional security feature that you should be utilizing is proper port security. As I mentioned before the easiest way to break into my network would be to come to my house, tear down a security camera and plug your device into the camera’s ethernet cable. The camera itself has its traffic locked down, but the port is completely open. To minimize this threat, each port on a network switch can be locked to a single MAC address, which is unique to each piece of equipment on your network. To do this, find the client that you want to assign to that port, in this case a Hikvision Camera. In the right hand panel you can see the device’s MAC address which we’ll need to copy, and you can also see the port it is attached to, which in this case is port 1 on my 16 port Gen2 Switch. Clicking on that link will bring up the switch, then you’ll select ports at the top and click the pencil icon to edit the profile of that switch. Any time I make a mac address isolation, I always name the switch port accordingly so I don’t end up pulling out my hair later if I ever need to change the device attached to that port.
Under MAC filter, paste in the mac address that you copied from the clients page, hit add, and then apply. You’ll see your switch change to provisioning and after it’s done the only device that will be able to connect via that port is that specific camera. Technically someone could spoof the MAC address of their device to still get into the network, but this solution is plenty secure for my purposes. If you’ve got government secrets stored on your network you may want to consider additional levels of security.
I mentioned earlier that I wanted my daughter’s PC to use the content filtered network, so what I’ll do is find her computer on the client list and take note of which port on the switch it’s connected to, then click through to that switch, and under ports hit the pencil icon to edit the overrides and select the family network as the available profile. This will force any traffic attached to that port onto that network. This is also how you would put an entire unmanaged switch onto a specific network, just make sure the uplink port your using is assigned to a VLAN and then all of the ports on the unmanaged switch will also be connected to that VLAN.
If you have unused ethernet ports in public places it’s best practice to leave these ports physically disconnected from the switch, which is called air gapping. This probably applies to very few homes, but in the off chance a business is using this guide, PLEASE don’t leave public ethernet jacks attached and connected to your main VLAN, they are the easiest point of entry for any attacker with physical access to your building.
So far the majority of the security that we’ve put in place is to protect us when we willingly attach devices to our internal network, but one of the largest vulnerabilities of any network comes when we override the implicit deny rule for incoming traffic. As I said before, basically all networks are set up so that internal traffic can leave, and returning traffic, called “established ad related” is allowed, but external traffic shouldn’t be able to initiate a connection with anything on your network. However, if you are running a service on your network like a media server, camera system, or home automation hub, you may need to allow that traffic by forwarding requests made to your external IP address to an internal device running that service.
This process is called port forwarding, and if you imagine your firewall as a giant building with hundreds of office doors, knocking on most of them will not get an answer, but occasionally when you knock on a door it will open and you will be lead down a hallway to another door which belongs to a specific device on your network.
The more devices on your network that are exposed in this way the greater your risk. In cybersecurity this is referred to as your attack surface, and best practice is to minimize attack surface as much as possible. Basically, instead of needing to ensure that each machine and service on your network is secure, which is often impossible with devices like security cameras and NVRs, you put all of your services behind a single door, and you fortify that door as much as possible.
If you are running a lot of services for a lot of people then you might setup a reverse proxy for this door, but for most people the best solution is to use a VPN. VPN in this context is not like the ones that you see advertised on YouTube all the time. A virtual private network, or VPN is a secure tunnel between one device and another. In the case of NordVPN or TunnelBear you have a secure tunnel between your computer and a device at a remote location called a VPN concentrator. This type of VPN allow you to securely send your internet traffic to this remote location through an encrypted tunnel, and then your traffic leaves that remote location via normal TCP/IP protocol exactly as if your computer was located inside of that remote site. This is useful if you’re trying to hide your traffic because you’re doing something illegal, or if you want to access content that is normally not available in your region.
The VPN we’re going to use is similar, but for a different purpose. Anytime we are outside of our home network, we will use a VPN tunnel to connect back to the dream machine pro, and after that all of our traffic will appear to be originating from inside the local network, allowing us to access our local services without having to expose them to the internet.
To set up a VPN, click on settings, and then advanced features. Scroll down to where it says RADIUS server. RADIUS is remote authentication dial in user service, though dialing in isn’t really a thing anymore. In this default profile you’ll want to define a user for each person who is going to log into your VPN. Each user has their own password to protect their account, and the VPN itself has a password to prevent unauthorized access. As you can imagine, best practice is for each of these passwords to be unique, don’t use the same password for your VPN and your users. Next head back over to the network section and add a new network. Give it a descriptive name, and under VPN settings you’ll select remote user. The only protocol supported by the UniFi VPN is L2TP, so you can’t change that, and under pre-shared key you will enter a secure password that your users will need to know to connect to your VPN. Enter the gateway and subnet that you want your VPN clients to connect to, and remember that you need to also adjust your local IP addresses firewall rule to include this new subnet. For name server, leave it on auto and make sure your default radius profile is selected.
To use this VPN on your remote device you’ll add a VPN configuration using L2TP, for server put in the external IP address for your dream machine, or use a dynamic DNS service like duckDNS for account put in the user name that you defined in your RADIUS profile, and the password for that user. The secret is the main password for the VPN that you defined when you set up the new network. If your device supports split tunneling you can configure only individual programs and services to use the VPN, but for the most part you should select “Send All Traffic” for the most trouble free configuration.
This solution isn’t perfect, and some services will not operate properly without exposing them to the internet, so you’ll need to weigh the security risks of each service you want to expose. You can see that when I try to connect to my blue iris server on the cellular network I get “no response from the server”, but after connecting to the VPN the server connects almost instantly.
In the future I may make a video about reverse proxies and more robust VPN solutions than the built in UniFi VPN, but for now this video has been long enough. If you learned something make sure to hit that thumbs up button so YouTube knows it’s a good video.
Thank you so much to my awesome patrons over at patreon for continuing to support this channel, if you’re interested in supporting this channel please check out the links in the description. If you enjoyed this video please consider subscribing, and as always, thanks for watching the hookup.
