2025-07-13 Configuring Separate VLANs for home and work on my TP router with LibreCMC

This was probably something I should have done a while ago, but with the addition of "security" software (read: proprietary root kits) being mandated on Linux work devices, I decided that it was time to segregate my home and work environments. Rather than go out and buy some fancy, new network equipment, I decided to attempt this using Virtual Local Area Networks(s) VLANs on my old router. With enough effort, I eventually got everything segregated to my satisfaction.

The first step was to try and understand the infinitely confusing network terminology and concepts and how they applied to my specific router. After much mulling over the documentation, head-scratching, and deciphering of jargon, I came to the following conclusions about my router:

Figure: Image of my router with attempted diagram of its architecture.

1. It consisted of two, not one, physical network interfaces. The first interface was dedicated entirely to the Local Area Network (LAN) while the second was dedicated solely to the Wide Area Network (WAN) (a.k.a. "The Internet" in my case).
2. The network interface dedicated to the LAN was a managed switch, capable of routing packets through a VLAN without the need of the CPU. This switch was named switch0 in LibreCMC.
3. There were four logical network interfaces on my device which concerned me. The first two interfaces were named eth0 and eth1 and they corresponded to the physical network interfaces for the LAN and WAN, respectively. The third and fourth interfaces, eth0.1 and br-lan, made up a driver-level VLAN for the switch named lan in LibreCMC; frankly, I did not understand the relationship between these two interfaces.
4. There were five ports associated with the managed switch. The first four ports were physical ports and clearly visible on the router. The fifth port was a CPU port which was for packets which needed to be routed outside of the switch.
5. The driver-level VLAN seemed redundant to me as there was only one LAN and the WAN was separated by an entirely separate interface.

I could not think of a way to use multiple switch-level VLANs since my goal was to separate my home and work networks, and I didn't see any way to actually segregate access with that type of VLAN. Still trying to wrap my head around all of the terminology, I set out to configure my VLANs.

Note that I got some inconsistent behavior across what I thought were the same configurations of the router. This might possibly have been due to caching, or other network behavior which I am unaware of. I've done my best to remember and document what happened at each step, but please be aware that there may be some inaccuracies.

My first step was to actually define multiple VLANs. The original configuration consisted of a single VLAN and one subnet for all physical ports. I begin by creating a new switch_vlan and interface configuration item named lanw (LAN-Work) (the latter using the same subnet as the original) in /etc/config/network for the new VLAN, and, since the ethernet cable for work was plugged into port #4 of the router, I dutifully moved port number 4 from the original VLAN to the new VLAN. This... didn't work. A network scan showed that my work device was still on the same LAN. I puzzled over this some time before finally counting up my devices and noticing that the device plugged into port number 3 was missing! I double and triple-checked both the router configuration and the physical port numbering and kept coming to the same conclusion: I had correctly configured port 4 in the router but port 3 was put in the VLAN! At some point in all of this I ended up in /etc/config/system looking at the LED configurations and noticed that LED#4 contained a port_mask value of 0x02 while LED#3 contained a port_mask value of 0x10. In other words, LED#4, which corresponded to physical port 4 on the router, was port 1 ($2^1 == 0x02$), and LED#3, which corresponded to physical port 3 on the router, was port 4 ($2^4 == 0x10$)! Overall, the router had the following mappings:

Physical port number	1	2	3	4
Hardware port number	4	1	2	3

So I tried re-configuring the VLANs with port 1 (4) in the new VLAN and ports 2, 3, and 4 (1, 2, and 3) in the original VLAN, and, sure, enough, the devices were now in the correct VLAN! Kind of silly, but I guess that's why it's called hardware and not easyware. And, yes, LAN-Work (lanw) is arguably not the best name given that there's also WLAN (Wireless LAN) and WAN, but it's what I came up with. Incorporating some later change I made to /etc/config/network (detailed below) I changed the following configuration from:

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '1 2 3 4 0t'

to:

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option ports '2 3 4 0t'

config switch_vlan
	option device 'switch0'
	option vlan '2'
	option ports '1 0t'

config interface 'lanw'
	option type 'bridge'
	option ifname 'eth0.2'
	option proto 'static'
	option ipaddr '192.168.20.1'
	option netmask '255.255.255.0'

While I now had two VLANs, the new VLAN didn't have Internet access. Or something. Either way, the next step was to define a zone for the new VLAN and enable forwarding for that zone from the new VLAN to the WAN so it would have Internet access. At this point something went terribly wrong and one or both of my VLANs lost Internet access and I ended up resolving the issue by giving each VLAN its own, distinct address range rather than letting them be duplicates of each other. As for my work machine on the new VLAN, I gave it a static IP while I worked on the new VLAN's configuration. At this point I'd made the following additions to /etc/config/firewall:

config zone
	option name             lanw
	list   network          'lanw'
	option input            ACCEPT
	option output           ACCEPT
	option forward          ACCEPT

config forwarding
	option src              lanw
	option dest             wan

Now, at this point I had the two VLANs separated, but not quite to my liking. The problem was that traffic between the old VLAN and the new VLAN was being explicitly rejected, while traffic between the new VLAN and old VLAN was being silently dropped. I don't trust inconsistencies like this. After some troubleshooting, I realized that connecting the machine in the new VLAN to my work VPN was mucking up some of my analysis and that I was a dolt for not considering that earlier. After stopping the VPN I got the same result: traffic between VLANs being explicitly rejected (ICMP port unreachable), but I actually preferred having it silently dropped. In fact, it appeared that machine names were leaking across the two VLANs, too. As I recall, I initially tried using rules in order to block the traffic, but it did not appear to be sufficient. Eventually I got the cross-VLAN traffic to stop by adding these two forwarding rules to /etc/config/network:

config forwarding
        option src              lan
        option dest             lanw
        option target           DROP
config forwarding
        option src              lanw
        option dest             lan
        option target           DROP

Satisfied that this had done the trick, I commented out the rules and left the forwarding items in place, thinking that the latter would be enough.

While I'd gotten my work machine to work on the new VLAN with a static IP, I needed to use DHCP, especially considering that I'd be bringing up VMs in bridged mode and they'd need a dynamically-assigned IP address. This was actually very straightforward: I added the following to /etc/config/dhcp:

config dhcp lanw
        option interface        lanw
        option start            100
        option limit            150
        option leasetime        12h

No mucking with dnsmasq or anything!

Around this time I took a break to go on a nice walk. When I got back and decided to admire my handiwork with a network scan, I found that traffic was flowing freely between the two VLANs. What the fuck?! I'm not really sure what changed, but I eventually ended up uncommenting my rules and noticing that I needed to fix the interface names (somehow I got wlan confused with lanw; shocking given my extraordinary naming choice), and this fixed the issue. Mostly. Except both VLANs showed both router IPs. Did this hurt anything? Probably not. But I felt that each VLAN should only see the router IP address corresponding to its VLAN, so I added yet another rule to each VLAN to block communication with the other VLAN's router IP. Not very elegant, but it worked. All together, my /etc/config/firewall changes were:

config rule
	option name             'block_h2w'
	option src              'lan'
	option dest             'lanw'
	option proto            all
	option target           DROP
config rule
	option name             'block_h2wg'
	option src              'lan'
	option dest_ip          '192.168.20.1'
	option proto            all
	option target           DROP
config rule
	option name             'block_w2h'
	option src              'lanw'
	option dest             'lan'
	option proto            all
	option target           DROP
config rule
	option name             'block_w2hg'
	option src              'lanw'
	option dest_ip          '192.168.10.1'
	option proto            all
	option target           DROP

So, I now had two VLANs, properly segregated. One thing still remained though: there was one work device which didn't have an ethernet port and could only connect to WiFi. Well, it'd be kind of silly to spend all this time segregating one of my work devices only to let the other onto my home LAN via WiFi, so I needed to somehow configure WiFi to use the new VLAN. This turned out to be really easy: all I had to do was add a new interface to the WiFi definition:

config wifi-iface 'default_radio1'
        option device 'radio0'
        option network 'lanw'
        option mode 'ap'
        option ssid 'plz no hack kthx'
        option encryption 'psk2'
        option key 'hunter2'
        option disabled '0'

LibreCMC was even able to run both of them at once! LibreCMC could also easily disable one of the interfaces in addition to the whole WiFi card itself, thus keeping my attack surface to a minimum. I was now set with regards to WiFi.

One last piece of network isolation remained, however. A quick check showed that I was able to access my router via SSH from my new VLAN. I would rather not expose my router to SSH attacks from my new VLAN, so I needed to isolate the SSH service to the original VLAN. Thankfully, this was also quite simple: I added the line option Interface 'lan' to the dropbear configuration in /etc/config/dropbear. Done!

After all this, my new router configuration could be visualized like so:

Figure: Image of my post-VLAN router with attempted diagram of its architecture.

Er, I guess the above diagram doesn't account for WiFi. Oh well. The two networks appeared to be pretty well segregated now. Though I decided to keep up the network scans until I grow tired of them. Just to be on the safe side.