The dreaded "DIY LAN" bug has infected me for many years. For the most part, it has simmered as a low-grade condition limited to watching videos about network switches, edge routers, repurposed server rack equipment, home labs, virtualization and so on. There have been occasional flareups which resulted in the purchase of gear in the hope that it might contribute to an actual overhaul of our local network. Over the last few weeks, the fever has reached a peak as I have finally undertaken the task of building a local network that should be independant of the router supplied by the internet provider. A fairly steep learning curve had to be climbed as I familiarized myself with two operating systems: OPNSense and OpenWrt (the latter for nought), managed switches and access points.

Table of Contents

1. Synopsis
2. The Gear
   1. A Firewall Device
   2. A Managed Switch
   3. A VLAN Aware Access Point
   4. A Dumber But Faster Switch
   5. The Home Hub
3. The Big Problem
   1. The DMZ Dance
4. The New Home Network Structure
5. The OPNsense Firewall
   1. Before starting
   2. Installing OPNsense
   3. Chickens and Eggs
   4. Basic Configuration
   5. Status and Update
   6. Complete the Configuration
6. The IOT VLAN
   1. Creating the VLAN
   2. Creating the VLAN interface
   3. Enable and Configure the DHCP Server
   4. Firewall Rules for the IOT VLAN
   5. Verification
7. The Managed Switch
   1. Verification
8. The Access Point
9. The Big Move
10. A Failure?

Synopsis

This is a rather long and not particularly entertaining post going over material covered elsewhere, in better fashion I am sure. Nevertheless there are three reasons to publish this.

• To encourage others to take the jump if so inclined. I procrastinated for three years and, now, I wish I hadn't.
• To counter plentiful but out-of-date information about Advanced DMZ on the Bell Home Hub 3000 (a.k.a. Sagemcom FASTFast 5566 modem). In June 2024, it does work. As far as I know, ADMZ provides the only way to isolate a local network from the Hub while retaining extra services such as TV and telephone for Bell Aliant clients and avoiding double NAT. I assume it is a workable alternative to PPPoE for Bell Clients (PPPoE is not available to Bell Aliant clients in New Bruswick and perhaps other Atlantic provinces). It also looks as if this applies to the HH4000.
• The post shows a relatively painless way to test trunk connections while building out the network. I found that reassuring. A Linux computer is needed to connect to the firewall and then to the managed switch to make simple ping tests. A Raspberry Pi or a similar small computer would be just fine. I am sure there is a way of setting up VLAN's in Windows and macOS, but I have not looked into it.

The Gear

As explained in the introduction, I have been on a mission to transform an eclectic collection of devices into a proper home network with a powerful firewall appliance and a virtual LAN to isolate the "internet of things" from the rest of the local network. Here is a description of the purchased gear and of the modem/router supplied by the internet service provider.

A Firewall Device

The firewall appliance, destined to be my version of the Deciso DEC675 Desktop Security or Netgate 2100 Security Gateway appliances, is a Lenovo ThinkCentre M90n-1Nano IoT purchased in March 2021, perhaps after viewing a video by Patrick Kennedy and reading the review by William Harmon at Serve The Home. It cost CDN$ 290 (plus tax) which was about the price of Protectli or similar barbone devices if I recall correctly. The M90n, on the other hand, came with 4 GB of DDR4 soldered SODIMM memory and a 128 GB nVME drive. It has a 2 core, 4 threads i3-8145U CPU with a base frequency of 2.1 GHz and a maximum frequency of 3.9 GHz and a built-in Intel UHD Graphics 620 display adapter which is not used. The Wi-Fi card, an Intel Wireless-AC 9560, is also not used. Most importantly, the ThinkCenter has two Realtek PCIe GbE network adapters (Realtek RTL8111K and a RTL8111H). Why two different models? I don't know nor do I know how they differ.

As can be seen, it also has two serial interfaces that can be configured to run as standard RS-232 ports. I have plans for at least one of them and, no, that does not mean adding an ancient X10 controller.

While Windows 10 came preinstalled on the drive, I never had an intention of using it. OPNsense (version 24.1.8 after two updates) is running currently on the machine. The choices seemed to be pfSense, OPNSense and OpenWrt. I chose OPNSense because I wanted some experience with what seems to be the most talked about open source firewall firmware. The presence of Realtek nics which apparently pfSense does not handle well, and some of the drama with pfSense convinced me to try OpnSense first.

In conclusion, the M90n-1 is somewhere between the OPNsense Reasonable and the Recommended configurations and has proven adequate for my modest needs.

A Managed Switch

Just when I purchased a 5-Port Gigabit Smart Managed Switch made by D-Link is totally beyond my recollection. It must be at least 3 or 4 years ago. The model is a DGS1100-05 (rev B). I do remember that it was a discounted item, perhaps because it was an end-of-life product as the GDS1100-05V2 became available. The timing is right because version 1 of the user manual for the V2 iteration appeared in July 2021. As far as I can make out, there is very little changed between my device and its replacement aside from the colour of the housing.

Why did I purchase this item aside from its attractive price (right now the V2 is available at CDN$ 42)? I could not resist the terms "Smart Managed".It was a good hunch, a managed switch is necessary for installing VLANs when the firewall has only two network interface cards.

A VLAN Aware Access Point

A state of the art (circa 2017), consumer grade, Xiaomi Mi 3G router was to be used as a wireless access point.

Its firmware was replaced with OpenWrt soon after purchase and updated to OpenWrt 23.05.3 for this experiment. It was easy to transform this router into a VLAN aware access point with OpenWrt. However the result was less than stellar with inadequate Wi-Fi coverage, especially in the 5 Mhz band. It was replaced with a Tp-Link Omada AC1750 (EAP245 version 3).

OpenWrt can be installed on this access point, but currently the stock firmware is still on the device since it can handle vlans.

A Dumber But Faster Switch

About 18 months ago I decided to upgrade part of my cabled network to 2.5 Gb/s. Three devices are on that segment of the network: a Linux desktop machine, a OpenMediaVault NAS and a Windows 10 computer only used remotely from the Linux desktop using RDP / Remmina. The OMV NAS has 2.5 Gb/s NICs but it was necessary to add a 2.5Gb/ PICe card to the two desktop machines. To link all this to the rest of the network I bought a TP-Link TL-SH1005 2.5Gbs switch.

I do not think this is available in Canada. It's a switch, it works, at 2.5 Gb/s, there's not much more to say. It does run a bit warm and I do not yet know how much power it consumes.

The Home Hub

My internet service provider (ISP) is Bell Aliant. It supplied a Bell Home Hub 3000. I believe that is a rebadged Sagemcom FASTFast 5566 modem. It must be realy fast!

This is a complex bit of kit, which provides Internet access, telephone service, cable TV and video on demand. It is connected back to the ISP with a fibre optic cable.

The four yellow RJ45 sockets are the four LAN ports to which our Ethernet wired devices are connected. The red socket is an unused WAN port. The two gray RJ11 sockets are DSL ports, which are not used, while the turquoise sockets below are telephone connectors, one of which is connected to all our land-line telephones. Not visible is the fibre optic connector which is under the hinged compartment on the right side. The hub has impressive wireless (Wi-Fi) capabilities.

The Big Problem

When we switched to our current ISP, the salesman assured me that it would be possible to put the router in bridge mode. Once the Hub was installed, it became clear that things were not that simple. Nowhere could I find a setting in its Web interface that would put the router part of the device in bridge mode. That was very easily done with the cable modem from our previous ISP. Nevertheless, I wasn't about to return to the previous ISP who charged 150% more at the time we switched over.

The "solution" was to take advantage of the Advanced DMZ capabilities of the Home Hub 3000.

With that, the OPNsense router is connected to the Home Hub as a DMZ device with a direct connection to the ISP outside the Hub's firewall. The HUB continues to function as before which means no changes for the home automation system and our Wi-Fi connected computers, tablets and phones until such time as the new network is up and functioning. This is really an ideal situation while testing the new home network.

By the way, it is not possible to configure the DMZ until the OPNsense router is connected to the Home Hub 3000. And that can't be done until OPNsense is installed as explained later.

The DMZ Dance

Unfortunately, the link between the OPNsense router and the IPS router DMZ is easily broken. The quickest way I have found to reestablish that link is to turn DMZ off and then ON. It sounds simple but it involves 7 steps.

1. Connect to the Home Hub 3000 Web administration page with a computer connected to a Lan port of the Hub.
2. Go to Advance tools and settings. You will need to enter the user password.
3. Click on DMZ in the Networking column.
4. Set the DMZ ON/OFF slider to OFF in the upper left corner.
5. Click on the [Save] button.
6. Once the setting has been saved, set the DMZ ON/OFF slider to ON
7. Click on the [Save] button and confirm the choice.

I have called this the DMZ dance. More about this later.

The New Home Network Structure

There's no claim that the new home network was meticulously planned. Following advice often repeated on the usual venues, the original plan had been to create three vlans:

Most recommend setting the third octet of the network address of each vlan equal to the vlan's id or tag. As it happened, I regularly use a VPN to access a remote system at 192.168.10.0/24, so I thought best to avoid having that network address on our home system, hence the single digit 3rd octets.

When installing OPNsense on the Lenovo, I just accepted all the default values. It assigned a network address of 192.168.1.0/24 to this local network and set itself up as the gateway with address 192.168.1.1. When I connected a computer to the lan port (port 1), it was assigned IP address 192.168.1.100 by the DHCP server running on the Lenovo. I could open the OPNsense graphical user interface at https://192.168.1.1. The computer had access to the Internet just as when connected to one of the Lan ports of the Home Hub. The Wan port of the OPNsense machine had a 159.2.xxx.xxx address which is the same public IP address as assigned by our ISP to our Home Hub 3000.

Basically, things seemed to be working and I could go on to construct the vlans on the OPNsense router. It struck me at this point that segregating the IoT devices in a vlan of their own was all that was needed because the Home Hub 3000 has a built-in guest network infrastructure which could continue to exist. So I simplified my plan.

The following graphic represents the new home network created with the hardware described above.

The graphic is deliberately vague about the access point hardware, because two different devices were tried as explained above. The tp-link EAP245 has a second Ethernet port, however given its mounting position, I do noting with it. The XIAOMI Mi 3G has two other ports. I had allocated one to the IOT network and the other to the LAN network which was useful when testing its configuration.

The OPNsense Firewall

I have no intention of describing the details of installing OPNsense on a X86 computer. Instead, I will link to resources that I found useful and provide some tips about what I learned in the process. As a starting point, I recommend the Beginner's Guide to Set Up a Home Network Using OPNsense by Dustin Castro. It is a simplified version of Set Up a Fully Functioning Home Network Using OPNsense which should be consulted because of its numerous screen captures. I pretty much followed Dustin Castro's advice which he broke into four steps.

1. Install OPNsense
2. Configure OPNsense
3. Configure network switch
4. Configure wireless access point

I dealt with the first two and then, only after testing the configuration including VLANs, did I tackle the more daunting managed switch and access point. It's not that the final two steps are that difficult, it's that there is not much information available. Being confident that everything upstream is working helps.

Before starting

Aside from the firewall device itself, here is some extra gear that will be needed.

1. A USB stick with the OPNsense image.
2. A monitor connected to the firewall device on which OPNSense will be installed.
3. A keyboard connected to the same device.
4. A "remote" computer with an Ethernet port and an Ethernet cable to connect to the Lan port of the firewall.

All this gear can be disconnected once OPNsense is installed because the latter is administered through a Web interface and SSH can be enabled. The "remote" computer could have been my main desktop Linux computer, but as hinted above I left that machine on the old network. Besides, the Linux desktop machine is not even in the same room as the firewall appliance, so the "remote" computer was either a relatively old portable Linux portable or a very old Linux portable, whichever was free when needed. There is no requirement to have a Linux machine for configuration. A Windows machine or a MAC could be used as long as it can be connected with an Ethernet cable to the Lan port of the firewall.

Make sure that the remote computer is configured to automatically get the IP address of its Ethernet interface from a DHCP server which will be OPNsense of course.

I will also strongly suggest that the Ethernet interface on the "remote" computer be the only active network connection. If the remote has access to the Internet through another connection, it will be easy to conclude that the OPNsense configuration is working when it is actually being bypassed altogether.

Installing OPNsense

The OPNsense installation is somewhat different from the typical procedure when installing an operating system on a desktop computer. Follow the instructions in the Install OPNsense section of Dustin's guide for obtaining the correct OPNsense image. Presumably, you will know how to copy that image to a USB stick and how to boot from that device. If you are a neophyte like myself, I will be so bold as to make a suggestion: skip steps 2 to 8 of the Beginner's Guide.

1. Do not press any key when prompted for the configuration importer
2. Press any key for manual interface assignment (I prefer to manually configure than using the automatic process)
3. Press “Enter” to skip the LAGG configuration
4. Press “Enter” to skip creating VLANs (will do this later in the web interface)
5. Enter igc0 for the WAN interface name (for the Protectli VP2420 – your interface name may be different such as igb0)
6. Enter igc1 for the LAN interface name (for the Protectli VP2420 – your interface name may be different such as igb1)
7. When prompted for an optional interface name, press “Enter” to skip configuration (will do this later)
8. Press “y” and “Enter” to continue
9. At the login prompt, enter the username installer and the password opnsense to continue with the installation

If you look carefully at the steps, they mostly skip doing things, so you may as well let OPNsense follow through with its default installation. Just watch and wait until you see the login prompt and then follow step 9.

After getting to step 17 and completing the install, reboot the router and remove the installation media (probably a USB stick) as soon as the reboot process is started. Again wait until the IP addresses of the Wan and Lan ports are displayed and, at that point, connect the Ethernet port of the remote computer to the LAN port of the OPNsense appliance and connect the WAN port to the Home Hub 3000.

Chickens and Eggs

That last throwaway sentence is puzzling to the neophyte like me. After the boot completes, OPNsense will display the IP address of its Lan port (192.168.1.1) and Wan port. On my system, I got something like this.

Of course I did not know which RJ45 connector on the Lenovo was assigned interface re0 and which was re1. Presumably, Dustin somehow knew which connectors on the Protecli were igc0 and igc1. Perhaps he had gained that information from previous installations. Without that knowledge, I just "poked" at the ports to find which one was the LAN port. That means checking for a valid IP address on the remote computer connected to one of the firewall RJ45 port. If after a half a minute or so, the interface has not been assigned an IP address, move the cable to the other port. Then the remote computer should be assigned an address on the 192.168.1.0/24 network. There was a fifty-fifty chance that the correct connector was chosen initially. Success looks something like this on a Linux remote. Try ipconfig on a Windows machine.

The other RJ45 connector is the WAN port for the Ethernet cable from the Home Hub 3000. Once those two devices are connected, it's time to configure the DMZ connection in the Home Hub web interface. If you are having trouble finding OPNsense in the list of connected devices, check the WAN port's MAC address with the remote computer. That address can be entered manually in the Home Hub interface.

If the OPNsense machine has more than 2 Ethernet ports, then the one next to the LAN port is chosen as the WAN port by the firewall. Presumably, this logical next port is also the physical next port.

Once the two connections are in place, a lot of grief can be avoided by checking that the firewall is providing access to the Internet. Two ping should suffice.

I am picking on Quad9 and Google, but any well-known public sites can be used. If the first ping does not work, do the DMZ dance. If the first ping works but not the second, there's a DNS problem and that may have to be resolved in OPNsense itself. It may be necessary to reboot and that may mean that the DMZ dance will be required.

Basic Configuration

Open the OPNsense GUI with the remote computer using specified URL which should be https://192.168.1.1. Since OPNsense uses a self-signed certificate, the browser will probably complain about security risks. Go ahead and insist on opening the OPNsense web administration page.

Since this is a first time installation, the installation Wizard will be displayed. Again I suggest you follow along with it. The developers of OPNsense have taken upon themselves to help new users of their software; take advantage of their effort. Anything done with the Wizard can be changed after. The idea is to get a working connection to the Internet through the firewall.

Status and Update

Ideally, it would be best to check on the status of the firmware (System » Firmware » Status). It usually requires a few seconds to display the details.

If it's taking a long time to show the status information then the most likely causes of the problem are

1. No access to the Internet. You can check this in a terminal on the remote computer by pinging 8.8.8.8. When the pings fail, that almost always means that the Advanced DMZ configuration in the Home Hub 3000 is not functioning and I have to perform the DMZ Dance.

2. No DNS servers are specified. In that case ping 8.8.8.8 works but ping google.com fails. Check if DNS servers have been set in System » Settings » General » Networking. It may also help to set DNS servers in Services » ISC DHCPv4 » LAN.

Assuming that networking is operational, then click on the [Check for updates]. If some are available, they will be listed in the Updates tab. If desired they can be installed. I would recommend doing a backup of the configuration beforehand: System » Configuration » Backups » Download configuration

Complete the Configuration

Continue with the suggestions from Dustin Casto and complete the OPNsense configuration once the firmware has been updated. Some suggestions were beyond my comprehension, so I more or less guessed at the correct value. Luckily nothing is final and it can all be changed at a later date. Again I would recommend backing up the configuration as things progress.

The IOT VLAN

At last, the interesting bits are at hand: creating the virtual local networks. In my case, there is only the one to create, but more could be added in the same way.

Creating the VLAN

To create the virtual IOT LAN go to Interfaces » Other Types » VLAN and click on the [+] (Add) button.

Fill in two fields in the Edit Vlan window:

• the VLAN tag and
• an optional description, here iot.

Note that the Parent is the LAN port. This means that the latter will transmit untagged lan traffic and tagged vlan traffic. So the router's LAN port (port 1) is an end point of what is sometimes called a trunk connection. I will test this latter to make sure it works. As suggested, the device name was left empty to let OPNsense generate a valid name. Because that name, vlan01, seemed a bit confusing as the VLAN tag was set to 2, I edited the definition and changed the name to vlan02.

The renamed vlan can be seen above. Click on the [Apply] button to actually create it.

Creating the VLAN interface

Go to Interfaces » Assignments

The newly created vlan shows up a device that can be assigned to a new interface. Give it a description such as IOT and click on the [Add] button. The new interface appears immediately in the table of interfaces and in the left menu under Interfaces.

I clicked on the [Save] button although I am not sure that was necessary. Click on the [IOT] interface name either in the Assignments table or on the left in the Interfaces menu.

Enable the IOT interface in the basic configuration and optionally check the Prevent interface removal box. As soon as the interface is enabled, the list of configuration items grows. Scroll down to Generic configuration and set the IPv4 Configuration Type to Static IPv4. I do not use IPv6 locally, so I left that configuration type to `None'.

Scroll down to the bottom and enter the IPv4 address of the IOT vlan in CIDR notation.

As per the tradition, the third octet of the IP subnet is the same as the vlan tag: 2. Later, I changed the static IP address to facilitate migrating the home automation devices to the IOT network; I did not change the vlan02 device name and left the tag at 2. It's just a convention and with only one vlan it can hardly be confused.

Click on the [Save] button. The changes will have to be applied by clicking the obvious [Apply changes] button.

However, OPNsense did kindly point out that the DHCP server range may need to be changed.

Enable and Configure the DHCP Server

To do that go to Services » ISC DHCPv4 » [IOT].

Enable the DHCP server on the IOT network. If desired set the range of IP addresses which can be assigned by the DHCP server to devices connecting to the network.

Finally, scroll down to the end of the page and click on the [Save] button (not shown above).

Firewall Rules for the IOT VLAN

The whole idea behind the IOT vlan is that IoT devices, including smart speakers, can communicate with each other and with the Internet but they do not have access to the LAN. On the other hand, we want devices on the LAN to have access to devices on the IOT network. If nothing else I want access to the home automation server. However, the IOT network is completely disconnected from the local network by default. We need to add two rules: one to open up the IOT network to the outside, and one to block access to the LAN network. I found How to Set Up a VLAN in OPNsense by WunderTech quite clear on this subject.

This is easily initiated by going to Firewall » IOT.

You will see that there are a number of automatically generated rules that are hidden. You can look at those if desired. For our purpose, click on the [+] (Add) button. That brings up a firewall rule editor.

Click on [Save]. We now see the added rule.

Click on [+] again to add a blocking rule.

Click on [Save].

Two rules but they are in the wrong order. If we had added the blocking rule first and then the pass rule we would not have to perform the next step.

Select the block rule by clicking on its checkbox. Then click on the [<-] Move selected rules before this rule button.

Voilà, the rules are in order, so click on the [Apply changes] button.

Verification

So finally, the basis of our new network is in place. But let's be systematic and test at the firewall's lan port that both the untagged LAN network and the tagged IOT network traffic is available. While there, we will check the firewall rules that control access to the two networks.

As explained at the beginning, I use a portable Linux computer to do this. Connect it to the lan port of the firewall appliance. The link is made with the Automatic Ethernet connection. As we can see, interface enp0s31f6 gets IP address 192.168.1.103 from the DHCP server running on the (untagged) LAN network of the firewall.

All the above pings show that the remote computer has access to the 192.168.1.1 gateway, that it has access to the Internet (9.9.9.9 is the Quad9 DNS server), DNS servers are working since google.com can be pinged. Finally, we see that the remote computer has access to the IOT vlan gateway 192.168.2.1 which is the OPNsense firewall.

But what about the IOT virtual network? By default, Linux does not handle VLANS, they must be enabled. I wrote a little bash script to take care of that. You can obtain the latest version of test-vlan.sh from my gists. I would suggest editing the default values at the top if needed.

I used the script to create a vlan interface over enp0s31f6 to the IOT virtual network.

We can see that the test-vlan interface has a static IP address 192.168.2.8 which is on the IOT network. So the lan port of the OPNsense router is indeed trunk end point for the untagged LAN network and the (virtual) tagged IOT network. To test the IOT network routing, disconnect the enps31f6 from the LAN network. The easiest way to do that is to disconnect the Automatic connection in the NetworkManager Applet on the task bar.

Time to test the firewall rules with ping much as before.

This shows that the remote computer connected to the IOT vlan has access to the gateway on that network namely 192.168.2.1 but no access to 192.168.1.1 and presumably any other device on the LAN network. It also has access to the Internet since the Google DNS server can be pinged. Don't worry about the fact that the remote computer cannot reach google.com. The problem comes from the fact that it has a static IP address and as such it did not get DNS server addresses from the gateway which it would normally get if using DHCP to connect.

The Managed Switch

There is no point trying to set up the managed switch until that trunk connection end point at the firewall (verbiage to identify the firewall lan port) is working. Now that we verified that the OPNsense is working as desired, it is time to set up the managed switch. Since I had played with the switch some time ago, I had to reset it to factory defaults to get access again. That is done by pressing the Reset button for slightly more than 5 seconds until the LEDs light up solid amber for 2 seconds. Here are the factory settings in effect after the reset.

• IP address: 10.90.90.90
• Subnet: 255.0.0.0
• Password: admin

So connect the remote computer to a port on the switch, create a static IP connection on the remote computer with an address such as 10.90.90.100 and then open the web interface of the switch at 10.90.90.90.

Once connected, navigate to System » System Information Settings » IPv4 Interface.

As can be seen I gave the switch a static IP address of 192.168.1.3 with the appropriate subnet mask and specified that the gateway is the OPNsense appliance. Click on the [Apply] button. The connection with the remote computer will be lost.

At this point I connected port 1 of the switch to the firewall lan port and connected the unmanaged tp-link switch to port 5 of the D-Link managed switch. My desktop machine which is connected to the tp-link switch got a new IP address from OpnSense on 192.168.1.0/24 and it could be used to log into the management web page now at 192.168.1.3. At this point, it is best to click on the Save button on the menu bar to write the changes in the settings to non-volatile memory.

The five port switch is fully utilized. Port 1 is used as a trunked uplink to the firewall, while port 2 is used as a trunked downlink to the access point. That amounts to asking that those two ports act like "dumb" switch ports bridged together and passing packets back and forth without changing them at all. The role of the last two ports (ports 4 and 5) is to similarly pass packets was long as they are meant for the LAN network (192.168.1.0/24). These are already untagged so there is nothing to do except block all IoT (Vlan 2) packets.

There is only one IoT device that has a cabled connection to the IOT LAN. It is a repurposed TV box that runs Domoticz, Mosquitto MQTT broker, Ha-bridge and other IoT-related services. That device knows nothing about tagged IP packets. So the switch must pass on IOT traffic to port 3 as untagged packets on 192.168.2.0/24 and conversely add a vlan tag of 2 to packets coming from devices connected to port 3 before sending them on to the other ports.

The 801.1Q VLAN settings to achieve the desired goal is shown above in 3 screen captures folded into one image. If I recall correctly, eth3 could not be marked as Untagged in the VID 2 (IOT) configuration without first making it Not Member of VID 1 (LAN).

Don't forget to [Apply] all changes in their respective pages and to [Save] all the changes at the end. The diskette icon is somewhat misleading, the action performed when activated is to write the settings to flash memory so that they will survive a reboot. This is not a true backup to external media which should also be done using the Save configuration option in the Tools menu.

I will admit that it took a long time to get to that result. I did not know what I was doing and the documentation is terse and definitely not aimed at newbies. So there was a lot of reading of posts on the D-Link forum to get to that configuration. The only way I can make sense of it is to assume that VID tag 1 (which cannot be deleted) is the default (native) vlan and that all traffic on this vlan is untagged. I believe this is the default configuration in Cisco switches.

A YouTube video by Doug Johnson about setting up VLAN's on three different Ethernet switches reconcilled me to the D-Link management interface.

Verification

Because my desktop Linux machine had continued access to the D-Link web page, and that it is connected to the managed switch through port 5 and the tp-link switch, I could conclude that ports 1, 4 and 5 were operating as expected.

As for port 2 of the managed switch it yielded expected results given that ports 1 and 2 were effectively bridge. In other words, port 2 on the managed switch should be the same as the Lan port of the firewall and it was. Both the untagged LAN traffic and the tagged IOT traffic was going through the port. I tested exactly as when testing the lan port of the firewall and got the same results so I will not repeat that here.

Testing port 3 should be very simple. This port is assigned to the IOT network and the traffic from it is untagged. So connecting the remote computer to it using an Automatic Ethernet connection should mean that the computer ends up a device on the IOT network.

So the remote computer did get an IP address on the IOT lan when it is connected to port 3 of the managed switch. Using ping to check routing, we get the expected results.

Note that this time, the google.com URL was resolved because the remote computer picked up the DNS server address from the firewall's DHCP server.

Testing from another computer connected to the LAN network also gives expected results, namely access to a device on the IOT network.

The Access Point

Again I will not go into the details here, but the XIAOMI Mi 3G router with OpenWrt firmware was put into access point mode following instructions from Setup APs with VLANs by open source is awesome. It worked, but the results were very disappointing.

The SIGMDELNET network is our current Wi-Fi network running on the Home Hub 3000 on 2.4 and 5 GHz. The other networks emanate from the Mi 3G. Both netlan-2 and netiot are 2.4 GHz wireless networks for LAN and IOT respectively while netlan-5 is the 5 GHz wireless network for LAN. The rate and signal strength of the latter were very disappointing. The desktop is only 3 metres from the access point yet it only attains half the connection rate and 70% of the signal strength compared to the Home Hub networks which granted are less than a metre away. No doubt that there is a problem of interference but I do want to leave a wireless guest network working on the Home Hub so that problem cannot be entirely eliminated.

So I looked about for a reasonably priced access point that had decent enough performance, on paper at least. The fact that the AC1750 (aka EAP245) came with a power injector weighed in the balance since I do not have a PoE switch.

As can be seen, I set up netlan on the two Wi-Fi frequencies with band steering enabled much like SIGMDELNET so that devices can connect to the 5 GHz radio if the signal is good enough and get relegated to the 2.4 GHz frequency otherwise.

According to this scan, the tp-link is not as good as the Home Hub but in practice I have not noticed the difference. Gratifyingly, the range is sufficient for our needs. So that CDN$ 85 investment saved the project.

Another hint here. Be careful when setting the wireless mode for the 5 GHz radio. I could not figure out why a computer that was quite near the access point was not being "steered" to the 5 GHz frequency even though it supported 2.4 and 5 GHz. Its Broadcom BCM43228 Wi-Fi module supports 802.11a/b/g/n but not 802.11ac so that I had to set the wireless mode to 802.11a/n/ac mixed.

The Big Move

As soon as the managed switch was properly configured, the 2.5 GbE segment was connected to it. The fixed IP addresses of some servers (a NAS, an old Windows machine, and an old Linux box) now on 192.168.1.0§24 had to be changed. The main Linux desktop computer is connected to the 2.5 GbE segment but it is a DHCP client so there was nothing to do there. Consequently the untagged LAN part of the new network system was being tested even before the access point was added. When the latter was in place, I moved my personal wireless devices, a couple of portables a few Android tablets and a telephone to netlan. For a week or two, I was the testing the system on my own. Finally, an opportunity presented itself; I was alone in the house for two days and could afford to move everything to the new networks.

The first bit of business was to move the smart speakers from the SIGMDELNET to the netiot wireless networks. The Echo Show was the most involved because of two-factor authorization, the older Echo Dots and Flex were easily coaxed onto the new Wi-Fi network. The only remaining Google Assistant was not too hard to switch over as soon as I found a explanation for a cryptic error message. It meant that the device had to be reset with a well-hidden switch. There is no practical reason to have bothered moving the Assisant, we just find its answers entertaining. I used to think that Paul Hibbert was exaggerating, but lately... I am no longer frustrated when Mme Google says "I can no longer do this", I just chuckle and wonder if Amazon will let whittle away at Alexa in the same manner or if it will to "pull the plug" in one swift move when it decides there's not enough profit in providing this service.

Moving most of the Wi-Fi-based home automation devices was done with one command send via the MQTT broker. That worked because these devices are running Tasmota firmware. Because they were all DHCP clients, the Wi-Fi devices ended up on the 192.168.2.0/24 IOT network. The home automation server on which Domoticz, Mosquitto MQTT and HA bridge run, was disconnected from the Home Hub and connected to the IOT network via port 3 of the managed switch. Now that server has a fixed IP address, 192.168.7.45 because 192.168.7.0/24 was the address of the Home Hub local network. I could have changed the server's IP address to 192.168.2.45 and then send a command to all the Tasmota device telling them that the MQTT broker address was now 192.168.2.45. Of course, that would not have worked given that the devices had been trying to connect to a non-existent broker at 192.168.7.45 after being moved to the 192.168.2.0 subnet. Tasmota is very powerful. I could have changed the MQTT broker address manually in each device's web interface. It would have been slow and tedious. Since both OPNsense and the tp-Link AP list the IP addresses of all the devices on the wireless netiot network, a relatively simple bash script could have made an HTTP request to each device with a command setting the address of the MQTT broker. If Alexa device discovery worked without a problem that would have been fine. However past experience made me very wary of using that service. Instead I chose to change the IP address of the local network in the Home Hub 3000 to something not used anywhere in the system, 192.168.70.0/24. Then the OPNsense firewall setting for the IP address of the IOT network was changed to the previous IP address of the home network, 192.168.7.0/24. Being impatient, I turned power off and then back on for the whole house at the distribution pannel. That way every device had to reconnect to the networks. That worked. Eventually all the Tasmota devices connected to the IOT network and then connected to the MQTT broker on 192.168.7.45. Furthermore, the Amazon smart speakers could control all devices as in the past. Nothing in HA Bridge had to be changed. By the way, it is sometimes necessary to power cycle an IoT device from the Domoticz interface at least once before oral commands send to an Amazon smart speaker will work. Don't know why but it is not a big deal as it is a one-time chore and it is only a small number of devices that require this extra step. Indeed, it could just be my impatience and the problem might have disappeared on its own.

To complete the change over, there were a number of non-Tasmota devices that had to be handled. The most important of these was the networked Brother printer/scanner/copier used by my spouse. Luck was again on my side. The printer had not been operational before she left so she would not expect it to work as soon as she returned. I fixed a gruesome paper jam (it's funny how recycling old pages will not work properly if they are stapled together!) and changed the Wi-Fi settings to put the printer on the netlan wireless network. I tested with my Linux portable and everything worked. Can't say that my partner found it easy to use the scanner with her Mac, but then that was nothing new.

There remained a few devices, a Raspberry Pi running mochas, a wireless W600 based switch and a couple of ESP8266 based thermometers with home-brewed firmware, that I needed to handle individually. There are IoT devices that were not online when the change over was done. I have a plan to use a very old wireless router and a small single-board computer with Domoticz and Mosquitto MQTT that will be able to pose as the original system so that these devices can be recovered when brought back online. A first generation Pi or a first generation Orange Pi Zero that are not doing anything could handle that task.

So now the new home network is running much as I wanted.

A Failure?

Why the trailing "Failure?" in the sub title? Because things did not work out exactly as expected, although the final result is definitely not as bad as feared while working on this project.

For one thing, there is no guest network on the Home Hub 3000. I should have realized off the bat that there is no such thing as an independent guest network, it has to be an addition to the "primary" network. I could not create a hidden primary network to which a visible guest network could be added. Much more problematic, the "cable tv" service will not work without a primary Wi-Fi network in place. In a way, we are back to square one because the primary Wi-Fi network of the Home Hub is functioning just as before. It handles the tv service and we will let guests use it when they visit. Hopefully, devices on that network are totally incapable of reaching the LAN and IOT networks on our new, "parallel" system. I say hopefully, because strangely enough I can reach the Home Hub at 192.168.70.1 from the 192.168.1.1/24 subnet. Cursory tests show that devices connected to 192.168.70.0/24 do not have access to 192.168.1.0/24 and 192.168.7.0/24. Maybe that's ok.

Thankfully, the biggest anticipated problem does not seem to be arising. Whenever the link between the OPNsense firewall and the Home Hub 3000, the DMZ dance had to be performed. No sequence of brute force rebooting of the Hub and the firewall (i.e., turning power off and then back on the devices) solved that problem. I thought that power outages would inevitably break the link between the firewall and the hub and that only a DMZ dance would fix the problem. Yet during the Big Move described above, I shut off the power to the house on three separate occasions and each time power was restored the DMZ connection was reestablished correctly. That contradicted a lot of admittedly old information read on forums. It also shows that all the details about some of the mistakes I made during the Big Move were not discussed. Let's assume that Bell and Sagemcom listened to the complaints and improved the firmware of the Home Hub 3000. For those that are tempted to try using DMZ with the Home Hub 3000, check version numbers against those of my device.

I should point out that it nerd confirmed that DMZ on the HH4000 (used by Bell for 1.5 Gb/s service) works reliably.

Right now, I feel that the true failure was choosing the Lenovo ThinkCenter. For almost exactly the same price, a fanless N100 system with 16 GB of DDR5 RAM, a 128 GB nVME SS drive and four Intel i226 2.5 GbE network interfaces can be had. That would be a good choice especially if a faster upstream connection (to the ISP) is foreseeable. There is a well-known downside to ordering devices from smaller distributors; one will not get the kind of support and documentation that Lenovo offers. Had the Lenovo been put into service three years ago, then the value proposition would have been better. At the time, 1 GbE seemed more than adequate; we had a 100 Mb/s network running over MOCA.

To put things into perspective, the edge router is not currently a bottleneck and won't be until such time as we obtain a faster service from an ISP. So all in all, I am pleased with the new home network infrastructure and look forward to exploring new capabilities.