|Router Security||Using VLANs for Network Isolation||
Website by |
Many computing devices need access to the Internet but do not need to interact with any other devices connected to the router. If you have ever used the Internet at a coffee shop, you fit this profile while drinking your coffee. Security increases when devices fitting this profile are prevented from seeing, let alone interacting with, any other devices connected to the same router. In coffee shop terms, this means your laptop is safer if the laptop computers of the other customers can't see it. Bad guys at the coffee shop can't hack into computers that are invisible to their network scans.
For lack of a better term, I refer to this as Network Isolation. Other may prefer to call it network segmentation.
Many devices in your home need nothing but Internet access. Among these would be a Roku box, an Amazon Alexa and an Internet Radio. I have a stereo receiver that can play Pandora and other streaming services. On a home network, the protection offered by isolating these devices is to minimize the impact of a hacked device. Likewise, a malware infested Windows machine can't spread its tentacles, if it can't see any other devices or computers.
A truly isolated malicious device is prevented from learning about the existence of any other devices in the home. It is fooled, by the router, into thinking its the only device connected to the router. All the other devices in the home are thus protected from being spied on. If the CIA hacks your smart TV, the router prevents the TV from seeing anything you do on your computer.
To be clear, allowing a wireless device to access nothing but the Internet means:
Truly isolated devices run inside a VLAN. Specifically, a VLAN that does not allow communication with other VLANs.
A VLAN is a virtual LAN. A network within a network. A logical (not necessarily physical) grouping of devices.
VLANs were not initially created for the type of network isolation I advocate here. As such, there is a configuration option for each VLAN that controls whether it is allowed to communicate with other VLANs or not. In addition, there is another configuration option that controls whether the devices in a VLAN can see and communicate with each other.
Consumer routers offer Guest Wi-Fi networks. When configuring a Guest network on a TP-Link router (screen shot) there is a checkbox for "Allow guests to see each other". Peplink does not offer Guest Wi-Fi networks, but the same concept applies to VLANs, only they use a more technical term - they call it Layer 2 isolation. TP-Link Guest networks also have a checkbox to "Allow guests to access my local network." With Peplink VLANs (there is more on this below) the equivalent checkbox is "Inter-VLAN routing." That said, VLANs are Guest Wi-Fi networks on steroids.
As an analogy, consider a pet store with many fish tanks full of fish. Since the fish in one tank can not interact with the fish in another tank, each tank can be thought of as a VLAN that does not allow communication with other VLANs. A better analogy would be if each tank had a curtain around it preventing the fish from even seeing any of the other tanks.
Devices that only need Internet access, are best isolated in a fish tank by themselves. They can't see the other fish tanks (VLANs) and they can't see any other fish (computers).
But, sometimes we do need the fish in a tank to interact with each other. If, for example, you want to use a mobile device to control a Roku box, then both devices have to be able to communicate. The same with Sonos speakers that can also be controlled by a mobile device. I am told that Chromecast is another example, as a mobile device needs to see the Chromecast to set it up initially.
The most secure setup would be to put the Roku, Sonos and Chromecast devices in their own VLANs, configured to allow the devices/fish to see other, and assign a single SSID to each of those VLANs. Then, when a mobile device needs to communicate with the Roku, for example, it logs into the dedicated Roku SSID. This is annoying, but security and convenience have always been enemies. Also, you may run out of SSIDs. As I write this, the Surf SOHO can create only three SSIDs (plans are afoot to increase this).
If a particular device, such as a Roku box, can be totally isolated most of the time and only rarely needs to communicate with another device in your home, then you might have it totally isolated by default and just enable sharing within its VLAN on the rare exceptions when you need it (thanks to Zach for the idea). Of course, disable sharing when you are done.
Before leaving the fish tank analogy, any time the fish in a tank are allowed to see and interact with each other, a big fish may eat a small one.
To make another analogy, most routers are single family homes, where everyone shares everything. A router that employs a Guest Wi-Fi network is converted into a two family home. Some isolation is offered by Guest networks, but truly robust isolation requires VLANs. VLAN support lets you convert a router into an apartment building with as many apartments as you need. Apartments (VLANs) can be large, to accommodate multiple devices, or small studios housing a single device.
SIMPLE AND COMPLEX VLAN EXAMPLES
The fish tank in the previous analogy can be thought of as the boundary or scope of a VLAN. Stepping out of the analogy, the scope of a VLAN actually consists of Wi-Fi networks (SSIDs) and Ethernet ports. On the simplest level a VLAN can consist of a single SSID or a single Ethernet LAN port. You can mix and match too.
Type 1 is basically a Guest Wi-Fi network on steroids. The devices using that SSID will be walled off from all other devices connected to the router (assuming that inter-VLAN routing is not allowed). You might use one such isolated SSID for actual guests/visitors and another one for IoT devices such as a Roku box, an Apple TV, an Amazon Echo, a Nest thermostat or an Internet radio. This way you can change the Guest network password without impacting the IoT devices. And, the Guest network can be disabled when its not needed.
As an example, of Type 2, I use a VOIP service that provides a small telephone adapter box. One end plugs into a LAN port on my router and the other end plugs into a land-line telephone. The Ethernet port used by the telephone adapter is in its own, really tiny, VLAN.
Roommates could use Type 4. Each person could have their own SSID and two LAN Ports assigned to their personal VLAN. In effect, this chops the router in half and never the twain shall meet. Likewise, someone who works at home could use type 4 as a way to isolate the computers/printers/etc that are used for work from all the other devices in their home. Someone who works at home and wants the best possible security might use type 3 and limit themselves to 2 or 3 LAN ports and avoid Wi-Fi altogether.
Are VLANs overkill?
VLANs IN THE NEWS
In October 2018, a popular IoT operating system, FreeRTOS, was found to have 13 bugs. FreeRTOS is specifically designed for microcontrollers inside IoT devices. In 2017, Amazon took stewardship of it and extended it such that IoT devices could be connected to Amazon Web Services. The bugs allow attackers to crash devices, obtain information from devices and even take them over. The article says nothing about VLANs or network segmentation, but clearly that is the solution here, both to prevent an IoT device from being attacked in the first place and also to prevent a hacked IoT device from seeing any other devices.
On October 9, 2018, security firm SEC Consult issued a big expose about the many security problems with Xiongmai video devices. Their article included this: "Xiongmai devices are used in various 'interesting' organizations/networks all over the world. An attacker can use the vulnerabilities to get an initial foothold in the local network and then use lateral movement techniques to gain access to other systems (lateral movement). Clearly Xiongmai devices need to be in an isolated VLAN.
On September 10, 2018, security expert Robert Graham wrote about IoT security and said "... by far the most important thing that will protect IoT in the future is 'isolation' mode on the WiFi access-point that prevents devices from talking to each other (or infecting each other). This prevents 'cross site' attacks in the home. It prevents infected laptops/desktops (which are much more under threat than IoT) from spreading to IoT".
On August 2, 2018, the FBI issued an alert: CYBER ACTORS USE INTERNET OF THINGS DEVICES AS PROXIES FOR ANONYMITY AND PURSUIT OF MALICIOUS CYBER ACTIVITIES. It is mostly useless and brain dead, except for this: "Isolate IoT devices from other network connections." That most routers can't do this, is not mentioned.
On July 18, 2018, Brian Krebs reported that the National Bank of Blacksburg Virginia was hacked twice. Each time, the computer of an employee was infected using a phishing email message, perhaps the most common form of attack. From this first computer, the attackers were able to gain access to other computers on the network, including those that ran critical banking systems. The first attack cost the bank $569,000 but that was not enough for them to learn their lesson - computers that read email should not be on the same network segment as critical servers that run the business. The second attack cost the bank $1,833,984. I wonder if their network is segmented now. After the first attack, the bank brought in cybersecurity forensics firm Foregenix to help. I wonder if Foregenix suggested network isolation.
Intel Active Management Technology is a component of many of their processors. It is a second computer inside a computer. A spies best friend. And, Intel is, in general, not very forthcoming about how it works at all. On July 10, 2018 they went public with three bugs in AMT. Two of the bugs are considered highly severe and both are exploitable "via the same subnet". One allows an attacker to execute arbitrary code, the other lets an attacker cause a denial of service. As much as possible, it is best to isolate computing devices on a LAN.
On July 5, 2018, the New York Times wrote about spying done by smart TVs. Most of the article was about Samba TV, which not only watches what is on the screen, but "can also identify other devices in the home that share the TV’s internet connection." The article quoted David Kitchen, identified as a software engineer in London, who wrote "... if you own a 'Smart TV' from any company you should run it on a different network than your NAS and other computers ... Ideally you run a TV on a different VLAN." Peplink routers can log all outbound requests made by a device on your network. With some work, the router might be able to prevent a Smart TV from phoning home while still letting it function as a TV. No one has written an article about that however.
On June 18, 2018 we learned of a bug in Google Home and Google Chromecast devices that leaked your precise location to another device on your LAN. The two Google devices didn't bother with passwords when contacted on the LAN and thus would provide a list of nearby Wi-Fi networks to any device that asked. Feed that information to Google and it returns a very precise location. At first Google refused to fix this but when Brian Krebs contacted them, they changed their tune.
The above was just one of a few stories from June 2018 focused on DNS rebinding attacks. The most professional such attack was by a team from Princeton University. See Fast Web-based Attacks to Discover and Control IoT Devices. For a DNS rebinding attack to work, the victim needs to visit a web page that contains malicious script and remain on the page while the attack proceeds. The attack fails if the victim navigates to another page, before the attack completes. They don't say what happens if the potential victim switches to a new tab. Their attack is much faster than the others described that month, it takes only around ten seconds to discover and attack IoT devices on the victims network. By attack, I mean their software can send commands to control assorted IoT devices or extract personal information.
On June 11, 2018, we learned that Tens of Thousands of Android Devices Are Exposing Their Debug Port. Specifically, some Android devices are incorrectly configured and leave TCP port 5555, used for ADB over WiFi, open. This is a huge security issue, as another device on the same network can use this open port to install malware on a vulnerable device. Unless of course, the network uses the type of isolation discussed on this page. Some devices that were found with their Android Debug Bridge (ADB) port open were tankers, DVRs, mobile telephones and an Android TV device.
The May 7, 2018 issue of the The New Yorker Magazine had a story by Nicholas Schmidle, The Digital Vigilantes Who Hack Back, that discussed a penetration test by a security company. First they made fake badges to get into the offices of the target company. Then, they "plugged a local-area-network device into an Ethernet port in a conference room, and left before anyone noticed. Using the LAN connection, they hacked into the financial institution's network and, among other things, briefly commandeered its security cameras. The company realized that it needed to make serious upgrades to its network." The upgrade it needed was network isolation with VLANs.
In February 2018, Consumer Reports wrote that Samsung and Roku Smart TVs are Vulnerable to Hacking. The article didn't go into Samsung in detail, but any Roku device or a TV including Roku software (TCL, Hisense, Hitachi, Insignia, Philips, RCA, and Sharp), can be controlled by any device on the same Wi-Fi network. Needless to say, Consumer Reports did not mention VLANs, but that is your only defense. And, they are wrong about the Wi-Fi requirement too. Roku is designed to be controlled over the LAN. They have documented their External Control Protocol. SSDP can find the Roku devices on a network (assuming no VLANs) and they listen on port 8060. Consumer Reports does some scare mongering, saying that these devices can be hacked over the web, from thousands of miles away. It is, nonetheless, a LAN side attack.
In January 2018 networking flaws were revealed in Sonos speakers. On the January 2nd edition of Security Now, Steve Gibson first suggested isolating IoT devices, but was stumped by the problem with Sonos speakers. He had no solution for the case where they need a device or two on the LAN to be able to talk to the Sonos speakers but you do not want anything else on the LAN to communicate with them.
This article, FREE zero-day for every reader: AT&T's DirecTV kit has a root hole - and no one wants to patch it (Iain Thomson Dec. 13, 2017) is a great illustration of the problem that VLANs can solve. "AT&T's DirecTV wireless kit has an embarrassing vulnerability in its firmware that can be trivially exploited ... to install hidden backdoors on the home network equipment..." A DirecTV installation includes a Linksys WVBR0-25 wireless video bridge that sends video and audio from a Directv Genie DVR over the air to multiple Genie client boxes that are plugged into your TVs. The bridge sets up a private wireless network, and acts as a virtual coaxial cable to your television sets. The wireless bridge runs a web server that is trivially easy to hack into. Someone with access to the home network could install malware on the box. When told of the flaw, AT&T did not respond, even after 180 days. What to do? The researcher who found this said "... users should protect themselves by limiting the devices that can interact with the WVBR0-25 to those that actually need to reach it." In other words, VLAN!
A story about a casino being hacked via a fish tank in the lobby is perfect clickbait. The Washington Post covered in in July 2017 (How a fish tank helped hack a casino) as did CNN (A smart fish tank left a casino vulnerable to hackers). A thermometer in an aquarium was used to get a foothold in the network. From there, the bad guys poked around the network and eventually found a high-roller database and stole it. If any device fit the profile of Internet access only (no visibility into the rest of the network or from the rest of the network) it would be a fish tank. Had the tank been connected to an isolated VLAN, the worst thing a bad guy could do would be to kill the fish by making the temperature too hot or cold.
On a more technical level, each VLAN gets its own subnet (sub-network). So, one VLAN might use IP addresses in the 10.1.1.x range and another VLAN would use IP addresses that start with 10.2.2.x. Each VLAN also gets its own DNS servers. They are, as the name implies, virtually LANs. All your VLANs can use the same DNS servers, or, each VLAN can use different DNS servers. If, for example, you put devices used by children into a VLAN, then that VLAN can use DNS servers that block porn. I am working on a page about DNS servers, but its only partially complete. This is a hobby, what can I say.
NOTE: IF DNS forwarding is enabled, then the router forces all DNS queries to be answered by the router itself. This over-rides the DNS servers specified for a VLAN.
To help you keep track of your VLANs, the Surf SOHO lets you assign each VLAN both a name and a number. Some useful names might be IoTvlan, VOIPvlan or GuestVLAN. The highest allowable number is, I believe, 4,095.
VLANs do not get their own passwords. If you assign a Wi-Fi network to a VLAN, nothing about the Wi-Fi password changes. Ethernet ports that are assigned to a VLAN are not password protected.
Many routers can offer some isolation but the feature is often disabled and limited in scope.
Support for VLANs is rare. Hardly any consumer routers support VLANs. None of the consumer oriented mesh routers support it. My recommended router, the Pepwave Surf SOHO, fully supports VLANs, but it is an advanced feature and disabled out of the box. You have to know a secret handshake (see below) to enable VLANs on the Surf SOHO.
The high end Synology RT2600ac, which seems to offer every feature ever invented for routers, does not support VLANs (according to the user guide for SRM version 1.1.2).
The isolation offered by the RT2600ac is a hodgepodge. On a non-Guest network, devices may or may not be able to communicate with each other depending on an AP Isolation option. The manual does not address sharing between Ethernet devices and non-Guest Wi-Fi users. On a Guest network, devices on the 2.4GHz band can not see devices on the 5GHz band. The manual wasn't clear as to whether AP Isolation was available for Guest networks within one frequency band. And, like many routers, Guest devices can access non-Guest devices if you so choose.
I don't mean to downplay Guest networks, they are a great security feature, even without full network isolation. Having a different password from the main Wi-Fi network lets you periodically change the password so that Guests don't get a permanent pass. Guest networks can also be disabled when they are not needed. And, they can offer some isolation of Guest users/devices.
That said, many consumer routers offer just one guest network and I don't think that's enough. For example, I suggest having one Wi-Fi network for devices that need to see other devices, one for actual guests or visitors and another for IoT devices. Parents with small children, may also want to isolate devices used by the kids.
THE TOTAL REVERSE
While this page focuses on giving a computing device access to the Internet and nothing else, sometimes we need the reverse. That is, we want a device to be accessible locally but not have access to the Internet. The firewall in any router should prevent incoming access from the Internet, at least as long as UPnP is disabled. A router that supports firewall rules, will let you block the device from making any outgoing connections to the Internet. No phoning home for ET. Needless to say, my preferred router, the Pepwave Surf SOHO, supports outbound firewall rules. Generally speaking, consumer routers do not offer outbound firewall rules.
PEPWAVE SURF SOHO VLANs
To use VLANs on the Surf SOHO, you first need to enable VLAN support, then define a VLAN (or two or three) and finally give the VLAN(s) a scope. By scope, I mean assign the VLAN to an SSID and/or a LAN port.
To enable VLAN support in firmware version 7, do Network -> LAN -> Network Settings (see above). In the "IP Settings" section at the top of the page, click on the white question mark in the blue circle. A small window pops up saying "If you need to define multiple VLANs, press here". Click on the word "here". A second window pops up that says "The LAN settings will be switch to advanced mode with VLAN support. Are you sure?" CLick on the Proceed button. Then, click on Apply Changes on the main menu bar (black horizontal stripe across the top of the screen).
Applying the changes takes you back to the main Dashboard page. Go back to Network -> Network Settings. Before creating new VLANs, there are two changes I suggest making.
As noted earlier, VLANs were not created for total network isolation and, by default, at least with Peplink routers, communication is allowed between different VLANs and non-VLAN devices (that is, stuff on the untagged LAN). So, click on "Untagged LAN" and turn off the checkbox for Inter-VLAN routing. This will prevent devices that are not part of any VLAN (untagged devices) from any and all communication with whatever VLANs you create.
Next, I would give the "Untagged LAN" a more descriptive name. This is the default name for the group of devices that are NOT in any VLAN. The default name is technically correct. Chunks of data (called packets or frames) transmitted on a network with VLANs have an extra tag that identifies the VLAN each chunk/packet/frame belongs to. Devices that are not part of a VLAN do not have their network packets tagged.
The name you choose can be anything that makes sense to you. Consider something like PrivateLAN or PrivateNetwork or MikeysPrivateLAN. Then click the gray Save button at the bottom of the window and, again, Apply Changes.
Back to Network -> Network settings. Now that VLAN support is enabled, the router will display a new gray button labeled "New LAN". It really should say "New VLAN". Click the New LAN button to define a new VLAN and you will see the screen below.
Previously I mentioned that each VLAN gets its own subnet, name, number and DNS servers. This is where we assign these attributes. It is also where we control whether the VLAN can talk to other VLANs and whether devices in this particular VLAN can see each other. Assigning most of these attributes is easy, assigning the subnet requires some techie knowledge.
The first field (IP Address) is not one I mentioned before. It is the IP address of the router, as seen from this VLAN. This is part of defining the subnet that the VLAN will use. In the example above, the VLAN is using the 10.22.22.x sub network. This means that all devices in that VLAN will have IP addresses that start with 10.22.22. All devices. Even the router itself. The first field is where you give the router an IP address in the new VLAN. In the screen shot above, it is device number 2. From the main network, the router is (using Peplink defaults) addressed as 192.168.50.1, but from this new VLAN/subnet, it will be addressed as 10.22.22.2.
Why 2? Most people use 1. It is best to avoid an IP address that ends with 1 or 254. For more on this, see the IP address page.
The field next to the router IP Address is complicated. However, the value shown (255.255.255.0/24) should be fine in almost all cases. It means that the subnet used by this VLAN can have a maximum of 255 devices (numbered 0 through 254). If nerds ask, this is a subnet mask.
Another subnet related field is the "IP Range" in the DHCP Server section.
All computing devices on a network need a unique number. Here we are dealing with IP version 4 numbers/addresses. Devices can either be configured to always use a specific IP address/number or be assigned one on a temporary basis when they join a network. Most of the time, devices use temporary IP addresses assigned by the router. The router itself is an exception, it has a fixed, static IP address. The system that loans out temporary IP addresses is DHCP.
In the example above, devices that don't have a fixed IP address will be assigned one ending in 100 through 199 (10.22.22.100 through 10.22.22.199). This implies that we can use fixed IP addresses between 1 and 99 and between 200 and 254 for devices that need one that never changes. A network printer, for example, is best assigned a fixed IP address. This range of temporary IP addresses was an arbitrary choice, it could just as well have been 100-250 or 30-252. The lowest number can not be lower than the number given the router. The highest number is 254.
That's the hardest part. Now, it gets easier.
The name of the VLAN goes in the Name field (see, easier). In the example, the name is Guest-VLAN. The name should be whatever makes sense to you based on who or what will be using this VLAN. If you intend to use the VLAN with a single SSID, then perhaps name it after that SSID. For example, the VLAN for SSID "michael" might be called "michaelsvlan". A VLAN for IoT devices might be called IoTvlan. My VLAN, that consists of a single Ethernet LAN port used by a VOIP telephone adapter might be called VOIPvlan. It is not clear how long the name can be or what characters are allowed/disallowed, so don't go crazy.
In addition to names, Peplink also assigns numbers to VLANs. The important attribute of the number seems to be that it is unique. Peplink refers to the number as a "VLAN ID" but its a number.
The number does not have to be related to the subnet, but being neat simplifies things. For example, you might assign the VLAN using the 10.2.2.x subnet number 2. Or, if you like 192.168 subnets, then consider assigning the number 4 to the 192.168.4.x subnet and 8 to the 192.168.8.x subnet. VLAN numbers do not have to start at 1 and do not have be consecutive.
The next field, "Inter-VLAN routing" is why you are reading this. Do not check the box. With this disabled, devices in this VLAN can access the Internet but can not access anything outside of their VLAN. Even if some other VLANs want to share stuff, this VLAN will not come to the sharing party.
The latest firmware has an option now shown here for a Captive Portal. Leave it un-checked.
I suggest enabling the DHCP server and disabling (not checking) DHCP Server logging. These can always be changed later. A Lease Time of one day should be fine. This is how long a device can use an IP address before it has to go back to the router and ask for another one. Opt to assign DNS servers automatically and do not check Bootp. There is no need to deal with the Extended DHCP option or DHCP Reservation.
When done, click the SAVE button at the bottom of the window and then Apply Changes, yet again.
To assign our newly minted VLAN to an SSID, go to AP -> Wireless SSID and click on the SSID name. As shown below, click on the drop down list box in the VLAN ID field. VLANs are identified both by name and number.
Isolating devices on this SSID/VLAN from each other, requires simply checking the box for "Layer 2 isolation" as shown below.
But, the Layer 2 Isolation option is not shown by default. As with VLANs, the router defaults to a simple mode and you need to know the secret handshake to see the advanced settings. As shown below, the secret handshake, in this case, is the white question mark in the blue circle. You need to click it, and then click again, where instructed (see below).
Be sure to click the Apply Changes button on the top of the screen, when you are done making changes.
At this point, you have a single, totally isolated, SSID. Congratulations.
NOTE: The advanced SSID settings stick around for a while, but you may have to do this again the next time. SSID configuration was split up into simple and advanced settings as of firmware version 7. Anyone using version 6 (which is the only supported firmware on the first hardware edition of the Surf SOHO) will see the "Layer 2 isolation" without needing a secret handshake.
The Surf SOHO allows for more than one isolated SSID. Simply create another VLAN for the second wireless network. The Surf SOHO can create a maximum of three SSIDs.
PENDING QUESTION: If a VLAN is assigned to two LAN ports and a single SSID that has Layer 2 isolation enabled, can devices plugged into the LAN ports see the wireless devices? Can the wireless devices see the Ethernet devices? Can the Ethernet devices see each other? I don't yet know....
When assigning Ethernet ports to a VLAN, you are presented with a choice that the User Manual does not explain - whether the LAN port is "Access" or "Trunk". ACCESS mode is the default, and represents the simplest case. At least initially, it does not need to be changed.
Recall from earlier, that network packets/frames that are part of a VLAN are "tagged" with the identifier of that VLAN. Most devices plugged into an Ethernet LAN port (laptop computer, desktop computer, VOIP telephone adapter, network printer, stereo receiver, Roku box) do not understand VLANs so the responsibility of tagging stuff falls to the router. In this case, the LAN port type should be ACCESS.
A device that does understand VLANs would be a smart switch. Smart switches are step up from dumb switches and a step down from a router. When a smart switch is plugged into a LAN port, then the type should be TRUNK. This tells the router not to bother adding VLANs tags, the smart switch has already done so.
The Netgear GS105E is a smart switch with 5 Ethernet ports and VLAN support. It cost about $40 in January 2018.
Whatever device is plugged in to a LAN port of type ACCESS, is assigned the profile you specify here. In the screen shot below, anything plugged into LAN port 3 will be assigned to the Guest VLAN and anything plugged into LAN port 2 will not be assigned to any VLAN. I use "MikeysPrivateLAN" as the name of my non-VLAN untagged network. An Ethernet-only network printer would belong in LAN port 2.
TRUNK ports are more complicated. The smart switch plugged into a TRUNK port can send data for multiple VLANs, depending on how its configured. But, the router is not bossed around by the smart switch. You can control which VLANs the router will accept from the smart switch. In the screen shot below, LAN port 1 allows the smart switch to send data for any VLAN, while LAN port 4 will only accept data for the IoT VLAN from the smart switch that is plugged into it.
The final nail in the total isolation coffin, is limiting the VLANs that can login to the router's web interface. For the best security, restrict router access to the private network. That is, prevent all VLANs from having direct access to the router.
To do this, go to System -> Admin Security -> Allowed LAN Networks (see below).
The "Allowed LAN Networks," defaults to Any which means users on all VLANs can login to the router. In the screen shot above, this has been changed and only MikeysPrivateLAN is allowed access to the router. Continuing the earlier example, this prevents anyone on the 10.22.22.x subnet/VLAN from logging on to the router using IP address 10.22.22.2. They won't even be able to view the logon page.
Continuing with the previous screen shot, the one in the Ethernet Ports section above, this means a computer plugged in to LAN port 2 (MikeysPrivateLAN) can access the router, while one plugged in to LAN ports 3 (Guest-VLAN) and 4 (IoT-VLAN) can not.
Interestingly, this setting also blocks the Peplink mobile app from talking to the router, if the app connects to an SSID/VLAN that is not allowed in. Learned that the hard way.
- - - - - -
The competition: Mike Potts documented on GitHub Using the Ubiquiti EdgeRouter X and Ubiquiti AP-AC-LR Access Point to create VLANs for each of 3 LAN ports and three different SSIDs. Here is an overview in PDF format. The heart of this is a 105 page PDF document with the full instructions. Compare that to this page. Seems much more complicated than the Surf SOHO (or any Peplink router). For example, look at all these firewall rules. Ugh. The EdgeRouter X is about $50 and the Access Point is about $100, so its roughly $50 cheaper than a Surf SOHO. That said, there are many costs other than financial. For example, Mr. Potts said "The only trouble with this router is that it is meant for professionals to use. You have to scrounge around forums for postings on how to configure specific items." Peplink routers are also targeted at professionals, yet the user interface is fairly easy to use.
- - - - - -
This is unlikely to happen often, but understanding the question shows a good grasp of things.
A regular switch (as opposed to a smart switch or a managed switch) is a relatively dumb Ethernet-only device that takes chunks of Ethernet data (packets/frames) in on one port and sends it out another port. Conceptually, a switch is the opposite of the network isolation described above on this page. Rather than prevent devices from seeing each other, it always lets all connected devices see each other. That's its job. That's why people buy switches. So, what do you think happens when worlds collide?
Suppose the Surf SOHO has a LAN port port assigned to an isolationist VLAN. That is, the VLAN has Layer 2 Isolation enabled and it is not allowed to talk to any other VLANs. Any device directly plugged into that LAN port can only see the Internet. It will be blissfully ignorant and shielded from other devices using the router. That's easy.
But, what if you plugged a switch into that LAN port? What then of the devices plugged in to the switch? Can they see each other as per the switch or can they not see each other as per the router and the isolationist VLAN assigned to the LAN port? When the router and the switch arm wrestle, who wins?
Note: This topic was originally part of the Pepwave Surf SOHO page but got too big for its britches.