Home network stack : using VLANs


VLANs, also called 802.1q, is a feature acting in OSI Layer 2, that provides L2 multiplexing and networks isolation.
It helps improving overall security and decreases network pressure by splitting the broadcast domains

At home, we tend to have more and more connected devices, and VLANs start being very useful for home usage too, whereas they've been present in wider networks for many years now (Office network, or more generally the Internet).

To support VLANs, you need to have some compatible hardware, which shouldn't be too hard to find. NICs (Network cards), NIC drivers, switches and routers should all provide VLAN support. This is not something uncommon, VLAN is really a de-facto feature now on most hardware, except perhaps the low-cost first-class entry hardwares.

If you've always plugged your devices on the same switch, and .... that's it : it works; Then this post is probably good to read ;-)

If you have not read /introducing-my-network-stack/ yet, you should do. Once more I'll explain here some theory, then detail what I did, at my home, for my needs ; forgetting about very advanced usages, such as GARP etc... as I don't need those at home at the moment.

Isolating networks at Layer 2

Layer 2 is the OSI data link layer. Whatever devices connected to the same L2 segment, they will be able to reach each other (assuming no L2 firewall, which is part of "advanced usage" so not covered here).
So if you plugin two devices on a traditionnal switch, they will be able to reach each other. That's just what the data link layer means. To achieve that, the Ethernet protocol is mainly used today, and Medium Access Control addresses in ports and NICs are used to address each other : MAC addresses.

Layer 2 is more complex than that because it is itself divided in two parts : the bottom one (MAC) and the upper one (LLC). It can turn exotic but we will simplify things here, no need to detail too much, let's keep focused.

Here is a traditionnal ethernet frame :

And here is one when VLANs are used (we use Ethernet 2 mainly nowadays):

Like you can see, when VLANs are used, every Layer 2 ethernet frame has 4 additionnal bytes added to it. We'll only talk about the rightmost 12 bits which are used to identifiy the VLAN ID. The other ones are used to classify traffic for prioritization, at Layer 2 yes. This is part of 802.1q and is called 802.1p

So for VLANs 802.1q, things are pretty easy like you could guess : only devices using the same VLANID will be able to communicate with each other on the layer 2.

When you setup the network of the device, you tell it to use a specific VLAN ID. Then, every frame the network card will send to the segment (usually reaching a switch), will be tagged (added) with the VLAN ID you chose into it. Should your switch support VLANs and be well configured, it will then only send the frame to the ports it knows participate to that VLAN, and not to the other ones.

That way, you clearly shrink the broadcast domain and isolate devices preventing them from directly talking to each other.
Like if those latter were connected on two different separated switches : they just can't talk together even if they are effectively connected to the same physical switch.

If you don't use VLANs, you send and receive what are called "untagged" frames. If you do use VLANs, you'll make use of 802.1q "tagged" frames.

In 12 bits you can address 4096 VLANs, and one NIC can be configured to use up to 4096 VLANs, that means that a NIC can talk to several different link layers on the same OSI Layer 1 physical medium. Isn't OSI beautiful ? ;-)

Remember, we are talking about OSI Layer 2 here. I haven't yet used the "IP" word, as this relies to Layer 3, stacked on top of Layer 2.
One layer 2 can support several different layers 3, for example on one LAN (with no VLAN), you could build 2 layer 3 IP networks. But the more you build, the more the broadcast domain will grow, which will sooner or later reduce performances or fully flood your Layer 2. VLANs are used to build several layers 2 onto the same PHY Layer 1 medium. All using Ethernet for our case.

The last important thing to remember for practice : the rule : two VLANs cannot communicate with each other through layer 2 (but layer 3, if a router is present). You isolate your networks within the same device (a switch).

VLAN usage under Linux

You need a compatible NIC (Network card), a compatible device driver, and the 802.1q Kernel module. So :

> modprobe 8021q

And under Debian with SystemD, you create your .netdev, .link and .network files in /etc/systemd/network. Something like this :

> cat /etc/systemd/network/10-eth0.link


> cat /etc/systemd/network/20-vlan99.netdev 


> cat /etc/systemd/network/20-vlan99.link 

> cat /etc/systemd/network/30-vlan99.network 


You should be able to create up to 4096 VLANs.
It is recommanded not to use the VLAN ID #1 and #0 and some other small ranges, which may have some consequences under some vendors (like Cisco) as being by default considered as the management VLAN or the untagged VLAN.

I personnaly make use of VLAN99, VLAN100, VLAN200 and VLAN50 and what it is usually called VLAN0 or VLAN1 : the untagged VLAN, that means a traditionnal Ethernet frame with no VLAN information.

Using VLANs with your switch

I can't detail everything here once more. Get some documentation about your own hardware.
I give you the basics for any switch. That latter supports ports. Mine has 12 ports.

Usually by default, VLAN filtering is not enabled, that means that by default, a switch should forward frames for any VLANs and for untagged traffic.
Enabling VLAN filtering, now you will have to tell your switch which VLANs are allowed to flow through each port. That will increase security and descrease the load on the switch host tables with independant VLAN learning.

Having turned on the VLAN filtering, now we need to configure the ports.
In what we call trunk port mode, ports can participate in several VLANs. In what we call trunk hybrid port mode, ports can participate in several VLANs as well as in the untagged VLAN. You must tell your switch which VLAN is allowed to flow through each port and what to do with untagged traffic (forbid/drop, leave as-is, tag with a specific VLANID).

Trunk port delivering traffic to hybrid ports

In access mode, the port only participates in one VLAN, and untag it at egress, while tagging it at ingress.
That means that you connect a device on this port, with no VLAN : default untagged traffic configuration, and when this device will start talking, the switch will tag the frames for you (at ingress), and treat them. When an answer frame will come from another port for than VLAN, the switch will send it to your port (assuming it is the target) and will untag the VLAN (at egress) for you.
This is very useful as there is no need to configure a VLAN on the end device : you plug it in, and you know that it will be part of VLAN X (and nothing more can happen, the device should not send tagged traffic, it will be discarded).

Trunk port delivering traffic to access ports

Like you can see, with clear VLANs table and VLAN filtering, you will need to identify each port as each device should be connected to one specific port of the switch, not randomly chosen.

Once more, we will not talk here (but perhaps in a future post ?) about complex scenarios, such as 802.1x authentication with RADIUS or EAP, dynamic VLANS belonging to client MAC addresses, and so more funny yet so powerful features of the Ethernet Layer 2.

Routing VLANs

VLANs are isolated at the layer 2. But if you put an IP router between two layer 2 segments - or between two VLANs which as their name suggests make "virtual" layers 2 - well ... you'll route the traffic.

Here we're going to start talking about IP. We'll use IP at layer 3, then TCP/UDP at layer 4 blablabla ... You get the picture.

So routing here is just routing. Nothing special.
We'll detail soon some real use-cases, but you can for example provide Internet access to VLAN 1, and to VLAN 2, (perhaps through different gateways ?) while still having both of them isolated. Simply don't route them at layer 3, or firewall them at layer 3.

You can route VLAN 1 and VLAN 2 together. Why not put them on the same layer 2 ?

First, because in layer 3 you get closer to "the goal" : the top, the layer 7 where the service resides. And then you can start being very accurate about what you do, especially using firewalls. Example : VLAN 1 can fully talk to VLAN 2, but VLAN 2 cannot initiate connections to VLAN 1. Or VLAN 1 can only talk to port 443 of any device on VLAN 2. You can also apply queues to limit bandwidth communication between those two VLANS. Etc...

And second : as the two machine groups are not on the same layer 3 IP, they will need a router to communicate with each other. There is no other possible way. As they are not either on the same layer 2 (different VLANs), they definetly cannot try to hijack the layer 2 to gain access to the other network(s). If they would have been on the same layer 2, a passive layer 2 study would have shown the broadcast related to the other network, thus a hijack could easily have been possible.
VLANs are also pretty nice for security : to isolate things.

There exists layer 2 firewalls, which can obviously only act (read/write/replace) layer 2 informations. You can for example with your switch, filter mac addresses, or change the layer 2 priority of frames. You could also only support IGMP as layer 3 protocol, and not IP (good for TV broadcasts). But still all layer 2 : who talked about ports (port 80 f.e) here ?

VLANs are just layer 2 networks, and a router's goal is to route them using layer 3.

Some use-cases and practice

At home, you can imagine several isolated networks.

  • One for adults, one for kids, one for IOTs
  • One for IOTs, one for everyone else
  • One for guest (wifi), one private for you (wifi)

So many scenarios...

I myself manage 5 different VLANs :

  • Private (untaggued traffic)
  • Management VLAN (VLAN99)
  • Multimedia VLAN (VLAN50)
  • VLAN to ISP#1 only (VLAN100)
  • VLAN to ISP#2 only (VLAN200)

Just the right complexity, those VLANs are small :

  • Untagged VLAN is a /24 IPV4 and a /64 IPV6
  • All others are /28 IPV4

The router has a link in each VLAN. It serves as DHCP/SLAAC for layer 3, gateway to Internet, firewall and all.

  • My network. Private. Traditionnal /24, untagged VLAN.
    Routed to #ISP1 and fail over to #ISP2. Member of the main routing table in the router : can access other BGP routed networked (through VPNs), ISP1, ISP2 and every other network.
    Supports my devices, PCs, laptops, the server and the NAS.
  • Multimedia network. Private. /28 on VLAN50.
    Supports IOTs (camera, TV, Hi-Fi amplifier, lamps/bulbs etc...), one wifi AP output.
    Supports the NAS that has participation too (to provide data for the TV and amp).
    Routed to #ISP2 only, as output (input traffic filtered). Member of a secondary routing table forbidding any communication with any other network, but Internet.
  • ISP1 network. Public. /28 on VLAN100.
    Supports one wifi AP output, the guest network. Allows "public" traffic : traffic I don't master, I don't myself generate (but guests).
    Supports some switch ports, as access mode VLAN. If a guest wants to plug-in physically and not use wifi, I'll plug on such ports.
    Could be QOS'ed with queues (bandwidth limitation). Could be firewalled harder.
  • ISP1 network. Private. /28 on VLAN200.
    Routed to #ISP1 only, as output (input traffic filtered). Member of a secondary routing table forbidding any communication with any other network, but Internet.
  • Management VLAN
    Supports management of the network units : the switch and the router. The NAS also has a participation for its management. Devices connected to management VLAN should make management services (ssh) only listen (socket bind) onto that specific interface, obviously.

So to sum-up things, you see that I use VLANs to differentiate traffics and networks and to push security one level further, with a management dedicated VLAN.
Why should my TV be able to talk to my PC ? No reason, so separated.
Why should a worm - hidden in my camera - be able to get triggered and scan its network, to find flaws in other devices, and infect them ? No reason, so separated, carefully watched and filtered.

I'm not paranoiac right, I just buid things and try to have basic security in mind, that's all. Many IP Cameras talk to external servers by default to open a hole in the NAT and be accessible using the vendor's infrastructure. That means that that later vendor can connect to your camera, whenever it wants to right ? What I usually do is cut off such traffic, as I can access my camera using a private VPN to my home, no need to give the keys to some foreign soul.

Let's practice

So, it's barely harder, than just pluging all together and run. Really. I don't know who reads my blog - I assume people not really knowing all that - . I assume programmers, hackers, right ? So... go ! It's just about network, and to me, it is fascinating (like many other computer science sub-division).

The switch

Reminder : I use Mikrotik hardware; RouterOS is the software.
Reminder 2 : You can try RouterOS, on an X86 virtual machine, for free. No special hardware needed (but you'd better emulate many network cards on your hypervisor) to try it.
If you want to use any else brand/software, just go ;-)

The switch will have to support 4 VLANs plus the untagged traffic, on different ports depending on what will be connected to it (detailed above).
Some ports will be in access mode, all other in trunk multi-VLAN mode. Some will stay free, I don't bother/care about them, I'm at home.

So let's start with the trunk port : it will support several custom VLANs as well as the untaggued VLAN. This mode is called the "hybrid" mode. Here is an example for a trunk in hybrid mode on VLAN50 :

> /interface bridge port add bridge=bridge interface=combo4-trunk ingress-filtering=yes frame-types=admit-all

> /interface bridge vlan add vlan-ids=50 tagged="combo4-trunk, ether3-nas, ether5-wifi" bridge=bridge

For an access port :

> /interface bridge port add bridge=bridge interface=combo1-tv ingress-filtering=yes pvid=50 frame-types=admit-only-untagged-and-priority-tagged

And ... that's all. Really, the setup is not hard to perform as we are looking for very basic features not enabling more-complex-advanced features such as dynamic VLAN assocation, MAC policies etc... Read your switch documentation, they all work the same : what port participate in what VLANs, and what to do with L2 traffic at egress, and at ingress. This is basicaly all.

The router

By default, the router routes everything, everywhere. That's it's goal. So any VLAN device, can access any other VLAN device (knowing it's IP) and everything else (the Internet f.e). Everything ends up in the main routing table.

We'll use Policy based routing, to assign VLAN interfaces traffic specific routing tables.

Let's show an exemple for VLAN100.
We create the VLAN on the trunk port (to the switch), we assign it an address, a DHCP server, some DNS configuration etc...

> /interface vlan print
  #   NAME             MTU ARP             VLAN-ID INTERFACE
 0 R vlan50-MM         9212 enabled              50 trunk
 1 R vlan100           9212 enabled             100 trunk
 2 R vlan200           9212 enabled             200 trunk
 3 R vlan99            9212 enabled              99 trunk

> /ip address print where interface="vlan100"
 #   ADDRESS             NETWORK       INTERFACE
 0     vlan100

> /ip dhcp-server print where interface="vlan100"
  0    vlan100  vlan100               dhcp_vlan100      3h       yes

> /ip pool print where name="dhcp_vlan100"
  # NAME                       RANGES
  0 dhcp_vlan100

Then we mark the traffic coming from this interface with a routing mark.

> /ip firewall mangle print where in-interface="vlan100"
0    ;;; VLAN100
chain=prerouting action=mark-routing new-routing-mark=VLAN100 passthrough=no in-interface=vlan100 log=no log-prefix="" 

Now, we create a new routing table, called "to_WAN_SFR", with just a default route using ISP#2 gateway (ISP#2 is SFR).

> /ip route print detail 
1 A S  dst-address= gateway= gateway-status= reachable via  sfp-wan-sfr check-gateway=ping distance=1 scope=30 target-scope=10 routing-mark=to_Wan_SFR 

Now, we create a new policy routing rule matching packets marked VLAN100, and say to lookup in the "to_WAN_SFR" table only.

> /ip route rule print 
1   routing-mark=VLAN100 action=lookup table=to_Wan_SFR 

That's it. But we can improve that.
We use a default route, so any packet from VLAN100 will be sent to the Internet gateway, including private address ranges and bogons. As my ISP will filter them, we could leave them flow but... They are private, they are not dedicated to be routed over the Internet. Leaving them routed to the Internet is just a no-go : in networking, please ... be clean. As much as possible.

To drop them, we could blackhole the routes or give a policy routing rule of "unreachable" to them (router will then send an ICMP packet to sources)
I decided to firewall them, because we can't blackhole them easily in every routing table, so I decided to firewall them using address lists and interface groups :

> /ip firewall address-list print where list="priv-addr"
  #   LIST        ADDRESS
 0   ;;; RFC3330
 1   ;;; RFC1918
 2   ;;; RFC3330
 3   ;;; RFC3330
 ... ... ...

> /ip firewall filter print                             
 3    ;;; Private ranges
  chain=forward action=reject reject-with=icmp-network-unreachable dst-address-list=priv-addr out-interface-list=ALL-WAN log=no log-prefix=""

Reminder : I only show the VLAN100 setup. Assume several routing tables, moving interfaces (as I may apply to a new ISP at sometime and want to ease that newcomer configuration).

Now we got VLAN100, that can only talk to the Internet. Every private address talk, such as trying to talk to other local connected networks, will be rejected (and could be blackholed as well either) with an ICMP type 3 code 0 : network unreachable : clean.

More advanced scenarios include using BGP and dynamic policy based routing, so that when a VPN goes up, it is added to the routing table as well, giving VLAN100 access to it, automaticaly. All this, could be firewalled and queued as well.
BGP is covered in other blog entries.

Talking about queues, why not limit the VLAN100 1Mbps Internet bandwidth for example ? But all opened by night, only limiting bandwidth during daylight.
Once more, not very hard to perform :

> /queue simple print 
0 name="queue1" target=vlan100 parent=none packet-marks="" priority=8/8 queue=default/default limit-at=0/0 max-limit=512k/2M burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s bucket-size=0.1/0.1 total-queue=ethernet-default time=0s-12h,sun,mon,tue,wed,thu,fri,sat

You see ?


VLANs have a use case in our home today. More and more devices tend to be connected, but wait ... Everything, tend to be connected to everything, everywhere, at every time ?

I don't share that idea at all. A network is a network, and it needs management when it starts growing like in nowadays personnal scenarios.

By practicing not-that-complex, pretty old, very powerful and mature networking concepts such as VLANs, one can really get the captain-hat in all that numeric home life. Would you leave young dozen children together in the same room and close the door ? Mmmmm ...
Are you aware that you can control extremely accurately what happens on your home network ? That you are responsible of what you send over the Internet, and measure your impact over that wonderful shared resource. Use it cautionnely please, respect others, like on the road, driving.

We don't talk about wide networks here (just think about them a minute). The complexity is mastered, you can script / cookbook / ansible ... automate many things, and you can prevent your silly pretty unsecured devices from reaching - should I give company names ? - 's servers if you don't want to, or from scanning your network items and spreading worms, that could leak to the Internet.
Should {insert-name-here} be aware that I just turned on my kitchen bulb ? No. It's not your business, it's my privacy.

By limiting the domains, by controlling the flows in the wires (or wireless) using basic VLANs and fine firewall rules, you highly limit the risks, the impacts... And when you talk about your stack, you know what you're saying.