Any VLAN expert here? Will be setting it up on my Mikrotik router and Unifi APs this weekend.
I come in search for somebody who knows a thing or two about VLANs or, if possible, had set it up for themselves at home (or work).
I have Mikrotik router and Ubiquiti Unifi APs. My goal is to have three separate SSIDs on my APs to differentiate clients. One group would be closest family (group 1), another friends (2) and the last one would be QR-setup guest wifi (3).
The reason is security. I run 24/7 server at home with many services that I don't want other people than #1 to see. But I also run ie. DNS there that I would like all to see (all three groups; or make them use other DNS via DHCP-set-DNS, ie. 1.1.1.1).
So far I believe everything from that list is doable with the right knowledge (that I have yet to achieve). But I would also like some other things and that's part of why I'm asking here.
- Is it possible to initiate connection from #1 to device in #2? Ie. from server to Raspberry that serves as temperature sensor for Home Assistant? Is it some built-in functionality like "higher number VLAN can access all lower numbers" or do I have to setup some exception on my router for speciric IP and port? Or specific LAN port (I have 24 port router, yet not everything is connected via ethernet)
- Do I have to set it all up in specific order? I have read that I can cut myself off from accessing my router if I setup VLAN incorrectly and that's what I don't want to do :-)
If you know how to setup VLAN and could provide some points to kinda carve the path I could stick to, I would be really grateful! I do not want manual of step-by-step instructions, rather some points to follow so I don't fall for something important I missed.
I will of course read up on it myself and will experiment a bit (I have old RB133 or maybe even RB433 around that I can use for learning), but it would be great to have some pointers.
Thanks in advance for any advices or recommendations.
Loaded question! I have in the past worked as a network engineer, but it was definitely one of many hats I wore so I am not an expert, but do have experience in the space. Please note that functionality with VLANs can depend heavily on what your equipment supports.
I think you probably already know this, but you need to combine subnets with access control lists (ACLs) to achieve VLAN security. So think through how you want to segment your network and build your VLANs ahead of time. It can be helpful to make a map showing connectivity in and out and IP segments to wrap your head around the whole thing. Leave enough space in each subnet for the number of devices you expect to handle at any given time, then add more! You can use an entire /256 per VLAN if you really want. You'll want to understand private IP space and what IP addresses your DHCP/router hands out as well.
Generally, the most secure way (and maybe only way) to configure VLAN connectivity is via ACLs . ACLs should have both outbound and inbound paths configured (similar to firewalling, if you are familiar - VLANs are basically network segmentation firewalls - note the difference between most stateful firewalls is that they will allow an inbound connection if initiated via an outbound connection while VLANs will not do that - you need the bidirectional rules to allow the traffic).
You can allow connections across VLANs by defining them specifically. So for your DNS example, you could allow two-way DNS traffic (port 53) from any VLAN to your DNS server's VLAN (or better yet, specific IP of your DNS server). You would also need to allow DNS traffic out from your DNS server to the internet for external look ups. You DO NOT want to allow incoming DNS traffic though as a matter of general security - this can allow someone to spoof internal requests or in some cases put bogus DNS entries into your server. I find for servers/services, being more specific (i.e. to the IP address) is preferred. This way, you can allow 80/443 out from your webserver, but NOT from your DNS server. Blocking port 53 out to the internet can help block DNS lookups (helpful if you are using a Pihole, for example - a lot of IoT devices hardcode DNS to specific servers so this can break things, but also make you more secure).
I think the best way to think of VLANs are as security or trust zones. So you could setup a zone for untrusted devices (I would put anything that relates to IoT into this bucket) and allow the most restrictive connections into and out of there - or only allow certain traffic out to the internet. Another zone would be for your most trusted devices (this would be personal computers, phones, etc) that you allow to other internal services. A 3rd middle ground would be what you call #2 above (trusted friends) that you might allow slightly more access. Personally, I would put "trusted friends" into the same QR-code guest level access which would be slightly less restrictive than IoT but more restrictive than your trusted devices, but I guess that depends on your use case (roommates for instance, you might want to put somewhere between most trusted and guest). You should also have your servers/services in their own VLAN so that you can control which of your client networks can access what in your server VLAN. So I think in your example, that would be 4 VLANs total - 1 for servers, 1 for trusted devices, 1 for friends, and 1 for guests.
One trap you don't want to fall into is over-segmentation. If you create too many VLANs (easier to do than it seems!) then you run the risk of over-complicating things, and all of a sudden you are editing dozens of ACLs to allow connectivity to a new service you just stood up!
It generally is possible to lock yourself out of something when messing with VLANs, which I would recommend setting up a port on VLAN 1 which should always allow you to manage your router directly. VLAN 1 is the default VLAN that always exists and is for management and device communication. Setup a port on VLAN 1 and make sure you can access your router from there before you start. You may need to hardcode/static assign an IP address on your machine to use VLAN 1 unless you have DHCP setup for those addresses. Typically, DHCP is not configured to assign addresses in VLAN 1 as that is a security risk.
Put a test device on a port you are assigning other VLANs to and test them as you build them out. Most routers will also have the nuclear option of a hard reset, either via config wipe or a phyical button to press to reset. You should probably familiarize yourself with what your hardware allows in that regard.
Hope my rambling helps. Happy to give further pointers if you have more specific questions.
Thanks for your reply! You are definitely the person I wanted to find.
We won't be speaking the same language for sure (I don't know technical names for many things) but I believe we understand each other quite well.
Your example with IoT, most trusted and "in-the-middle" VLANs is spot-on on what I want to set up. I have only one server that runs most of the services directly with Home and Music Assistants being only two that run in Docker. I also run NFS on this server that hosts my home folders. Maybe have server and desktops in their own VLAN then to minimize setup needs for their communication?
If I understand correctly - firewalls allow ie. for me to connect to internet server and then get the data back to me because it was innitiated by my own internal connection (I supposer source and destination has to do with this). VLAN doesn't do this if I don't set up both ways communication by myself. I will have a look at ACLs as this sounds familiar yet I didn't do anything with it yet.
Let me spin-off a bit about the DNS - I have 24/7 DNS on public IP that is open to the internet - This is desired configuration. How should I go about securing it while still being public reachable? I don't care if somebody (anybody, everybody) uses it as their DNS, I just want to not be spoofed. I suppose some firewalling our routing rules should be in place...
I will certainly be bck as it is already night time here. Will setuo one of the Mikrotiks as test mule that I can hard reset if I have to and I may be coming back with a bit of questions if I get stuck or doesn't understand something.
Thank you for your insight and help!
This is certainly one way to do it, but realize that all traffic within one VLAN will always be allowed - there will be no blocking of anything on any port. At that point, if you want to restrict communication between devices you would need to do so on the device itself via firewall rules. Even if you only have one server, I would still recommend putting it into it's own VLAN so you can block ports as needed. Bringing Docker into scope might complicate things slightly, as you are also going to be dealing with the virtual networking layer on the host itself, but I would imagine if you have all your services up and running on it currently that won't be too much of an issue.
This is correct. Most modern firewalls (note, not ALL) are what is known as stateful - which means they track in their own memory all connections flowing across them and keep the status of each straight. So, if your computer requests a webpage, it sends a request out to the webserver and the webserver replies with the page (this is highly simplified, but you should understand). The inbound connection from the webserver is allowed by the firewall because it is tied to the request that was initiated by your computer in the first place. In a stateless firewall (or with a VLAN ACL) your computer would be able to send out the request, but the response would not be transmitted (unless the traffic is specifically allowed back in). This just means you generally have to make a rule that says something like "Allow HTTP from VLAN 10 to Internet" and a separate rule that says "Allow HTTP from Internet to VLAN 10." Again, I'm oversimplifying here but that is the general idea.
Generally allowing DNS requests to your server is fine, but you do not want to allow zone transfers. There are a lot of articles about securing DNS servers, ranging from simple to very complex. Without knowing more about your specific use case for running a publicly available DNS server I probably can't help more there. I think, in general, limiting access to port 53 and making sure the administrative side of the server is locked down are good first steps.
Something else I should note about VLANs - they can break certain services that use what is known as "ephemeral" ports. These are services that either negotiate a port to use as a part of their communication protocol or switch ports regularly. One common example would be BitTorrent, which can be configured to either use one specific port, or to negotiate a port within a particular range. Some VOIP or other video calling services also use them. Just be aware that troubleshooting these can be hard, and may require you to open up wide ranges of ports for them to function. This is where firewalls become more useful than VLANs when trying to manage user traffic - however we may be veering very far from your initial concerns here :)
I know one thing about VLANs, which is that they're just quotation marks for packets.
On one physical link (Ethernet cable or SSID), you can send untagged (normal) traffic, and also traffic that is tagged with a VLAN number that it is supposed to belong to.
Usually, you use this to put different devices on different networks without having to run physical cabling and install routers and APs for each network. You can take two VLAN-aware AP and tell them to connect SSID X to VLAN Y, and connect them with one Ethernet cable, and devices on both ends on corresponding SSIDs will be on the same network as each other, but not on the same network as other SSIDs.
With a physical router the easy thing to do is assign a VLAN to a port, so traffic tagged with that VLAN internally will go in and out that port without tags. Then whatever you plug into that port is on that network and not on the other networks. The device you plug in does not need to know about VLANs.
If you want to grant a device access to multiple VLANs, you can have multiple physical NICs and plug them into router ports on different VLANs, or you can plug it into a port on the router that is set to carry traffic from multiple VLANs, with tags attached. (Plus you can decide what VLAN if any should send traffic out that port without a tag.) Then on e.g. Linux you can set up an Ethernet interface for each tag value on the base interface. So to the software it looks just like having multiple NICs, but they're virtual.
If you have multiple routers or VLAN-aware switches or VLAN-aware APs, you want to connect them together via ports that are set up to carry all the traffic for all the VLANs with the tags on. Then ports on VLAN 3 or whatever on any switch or router in the setup will be connected to each other, and everything on all VLANs will ride the shared cabling between switches/routers.
The other way to get a device to be able to talk to devices on other VLANs' networks is by actually doing internetworking. Basically, since these are separate networks, you can route between them. If you set up your router to be the default gateway and DHCP server on VLAN 1, and also the default router and DHCP server but with a different IP range on VLAN 2, then when hosts on VLAN 1 try to dial addresses on VLAN 2, they will see the IP is not on their network and send the traffic to the router, which will then see that it has an interface on the target network and forward it along (unless the firewall is set to block it). You can configure firewall rules on the router to do things like let hosts on one network open connections to and get responses from hosts on another, but not the other way around.
Anything that uses broadcast packets (which e.g. IoT devices might use to find their hubs, or anything that advertises itself to the local network uses) will stay within a single network and won't route through a router separating two networks.
It helps here to think of a router as a computer plus a VLAN-configurable switch. The router has a switch port that talks to its processor, and you can configure VLAN assignments for that just like for all the physical ports. Often this is used to give a router WAN and LAN ports: traffic from each kind of port arrives at the processor tagged with a different VLAN, and the router processor's OS has a virtual interface on each and routes packets between them. So if you do something like turn off connectivity between the router's processor and all the other ports, or set it up so that all the physical ports are on the VLAN that the router thinks is WAN traffic and there are no LAN ports anymore, you can indeed lock yourself out of whatever web UI it has and need to do a hard reset.
This is definitely what I wamt to do - one router, more VLANs with my APs serving more SSIDs with different VLANs but connected to router via one cable.
I don't use switches, I run dedicated cables everywhere, but I will definitely have at least one switch in the future (the fact that I hate, but I don't want/can't run more cables through the conduits in the wall.
With physical connection I plan on deploying VLANs on ports of the router. I would like client-free config as much as possible and this, to my very limited knowledge, should do.
I may setup more than one DHCP network (ie. 192.168.1.0/24 and 192.168.2.0/24) and have them for each VLAN, I may also dedicate onlypart of the same network/pool to each VLAN. I still don't know on that.
This in-between-VLAN communication will be the worst thing about the whole setup. I don't do enough networking to fully understand it, yet I know about port fowrarding and just a bit about IP routes. But for basic setup and differentiation between "trusted" and "public" clients this doesn't concern me at the moment. I can always set "public" clients to use other DNS in the internet and not allow them completely into "trusted" VLAN. This will be my basic setup and from there I can start lewrning about routing between them.
Thanks for your insights! I will compile them with other'sand make use of all your combined knowledge.
If you don't hear from me since monday, I'm still deep in VLAN stuff and unable to connect to the internet :-D
Good luck!
If you only have a few hosts that need to talk to both trusted and public clients, and they're all things like Linux servers, you might be best off giving each of those hosts interfaces on both the trusted and public VLANs, and doing the firewalling on the host to say what should listen on which address and what ports traffic should be allowed to from each interface. Then you can avoid dealing with setting up good firewall rules at the router for access between subnet.
Though you might need to worry about turning off IP forwarding on those hosts or really writing your firewall rules to filter by receiving interface: I can send a packet addressed to your private-VLAN IP to you over your public-VLAN interface, and you might route it to your own IP and then handle it.
If it would be possible I would like to do no client side configuration at all, everything within router. If it would be too much work, I may simply forfeit the whole "sometimes I may need to access between different VLANs" thing. The first step would really be making my "trusted" VLAN and making sure it works. From there I will make "public" VLAN for pizza delivery guy so that I can pay using card - bad cellular at my place (pizza delivery guy being great example, but I also mean neighbours, kids' friends etc.). If I manage to make it that far only then I will actually go for some advanced stuff.
I used this when setting mine up. While specific to the Ubiquiti space, I'm sure the general themes will be the same for you: https://github.com/mjp66/Ubiquiti/blob/master/Ubiquiti%20Home%20Network.pdf
Thanks for the link. I'd rather have some points to go along than reading such complete manual. I'm learning lots of things by trial and error, but since badly setuo VLAN can cut me off, I wanted to ask questions before going into it.
It is good to have such manual though as I have a place to look for info if I don't understand something or I get stuck. This might come in handy.