Home networking

[zeeclor]

“Networking is hard. Let’s go shopping.” — Barbie

@Belfry

The DrayTek can do it, but the terminology is different in the UI. Rather than using NAT rules, you can set up a wildcard * redirect of all DNS queries to an internal server (which is almost certainly building NAT rules in the background to make the redirect work).

This article on the DrayTek KB covers the config, and although the 2927 isn’t explicitly listed in the article, the option looks to be in the 2927’s UI according to the demo under Applications > LAN DNS / DNS Forwarding.

Thanks @Belfry. I am surprised and feel guilty that this turned out to be such an easy thing.

Inspired by this and @Kangie’s suggestion that vLANS seem complicated but are easy once you get your head around it I have spent the last week playing with my network. After making multiple changes I am back to where I started.

In summary (read TL:DR), my conclusion from all this is that making network changes involving these technologies requires careful planning, the right equipment and a test suite to determine what you break with each change.

In detail, I think the Draytek is a very capable router and will stick with it. Having said that my N100 acting as a home for an OPNsense install is coming today or tomorrow. I will bring it to HLB on Thursday night.

I run various servers at home mainly in docker containers. The docker servers are vms on proxmox on the main backbone. I have an arrs suite which the TVs and laptops can access. It runs over the net via a dedicated VPN. I have various cameras around and in the house. They talk to a motioneye docker server. Some of these cameras are wired and some wireless.

I have two old EdgeRouters X that can do vLANS. I note that there is an update to the interface to make it more consistent with modern Unifi GUIs. That is cool but they are tiny routers and definitely fiddly to configure.

My access points are an Ubiquiti U6-mesh and a FlexHD. They both stopped working during the week after running an overnight upgrade. That was fun!

It turned out that my docker Unifi controller was end of life at the end of 2023 and admittedly I had not looked at it since then. The upgrade to the new version that cleaves the monogodb server into its own container was straight forward. Straight forward in the techie sense that after you tried a few things, read some documentation, tried a few more things and then did exactly what the documentation said, it worked.

The pi hole had had various lists added to it as we have previously organised. Turning on the Draytek redirection made my desktop connection essentially unusable. I reverted to no DNS redirection.

During the course of the week the arrs suite became flaky, the cameras could not be connected to the back end and the spouse became irritable with frequent reboots of the router.

My plan when my new requirement comes is to sit down with a big piece of paper and map out what needs to be done, work out how to test if a particular change breaks one of my “essential” services and try one thing at a time.

Wish me luck.

[Belfry]

Thanks for the tip about the EdgeRouter upgrade. I had a quick skim of the release notes and may get mine out of the box to have look at it in the coming weeks after a few more people have tested the new release. I’ve not regularly used Ubiquiti gear in several years, but when I did I always found that waiting for something ending in .0.1 or hotfix was a less frustrating approach overall!

@zeeclor

Inspired by this and @Kangie’s suggestion that vLANS seem complicated but are easy once you get your head around it…

Agreed. I think that the slightly different terminology and configuration methods with every vendor doesn’t help. It’s the type of thing where it’s helpful to understand the high level theory, then once that makes sense, figure out how the theory maps to your preferred vendor(s) terminology.

@zeeclor

In summary (read TL:DR), my conclusion from all this is that making network changes involving these technologies requires careful planning, the right equipment and a test suite to determine what you break with each change.

Also agree with this, but at home I’ll admit to frequent configuration changes using the below approach too. It’s a bad habit but the stakes are a lot lower on the home network, so .

Something like draw.io can be helpful to do rough sketching out, although I’ll normally use scrap paper and a pen because I find that easier than trying to fight with Visio, draw.io, et al. I think you’ve got a good plan there to get started with your “big piece of paper” idea too.

Looking at the rest of your post - a few places that might be fun to start:

• Set up a separate VLAN in OPNsense/your switch/etc. and spin 1-2 VMs in Proxmox with that VLAN tag on their virtual NICs. Route between that VLAN and the rest of your network using OPNsense.
• Move a single or spare camera over to a separate SSID/VLAN and get that working in motioneye either via OPNsense routing between those VLANs/subnets or by setting docker up to tag traffic with that VLAN (here be dragons - I’m not familiar with docker and assume it can tag traffic but have no idea?).

Once you’ve set up a few test configurations and get the rough gist of the implementation, that’ll give you an idea of what your gear can do, and how to work with it. There’s probably no point in setting goals and mapping things out until the theory makes sense and capabilities of your equipment are known. I’m sure others in the group will have different views. I’m a big fan of the “just screw around with it and try to solve a real world problem in a low stakes environment” approach.

Finally, if you have the gear/physical space/inclination, setting up a test & eval environment can help keep your “production” stuff online (i.e., keep your family happy) and give you somewhere where you can tinker freely. In this instance, plug the WAN of your new OPNsense router into the DrayTek’s LAN, and have the “public” IP of the OPNsense be a private IP assigned by the DrayTek. Experiment all you want with OPNsense and on the network past the OPNsense box with the knowledge that you’re behind the DrayTek’s firewall and aren’t tinkering with the DrayTek’s config either. This sort of config gives you a special LAN to ruin, it’s over there.

The Simpsons - Special Cake For You To Ruin

[jdownie]

Top notch meme work as always @Belfry !

I’m still grinning after yesterday’s Dr. Evil !

[zeeclor]

@Belfry

Move a single or spare camera over to a separate SSID/VLAN and get that working in motioneye either via OPNsense routing between those VLANs/subnets or by setting docker up to tag traffic with that VLAN (here be dragons - I’m not familiar with docker and assume it can tag traffic but have no idea?).

Thanks @Belfry. That worked.

I have docker inside a debian vm inside proxmox so I thought this would be hard but like all things once it is up and running it seems easy.

You activate “VLAN aware” in proxmox on the interface you intend to use.

In the vm on that machine apt install vlan to get the 8021q module installed and then create the vlan itself. e.g.

sudo ip link add link ens18 name ens18.20 type vlan id 20
sudo ip link set dev ens18.20 up

Then create the docker vlan network. e.g.

docker network create -d macvlan \
  --subnet=192.168.20.0/24 --gateway=192.168.20.1 \
  -o parent=ens18.20 vlan20

Finally add that network to your docker container.

service:
snip 

  networks:
      - vlan20
networks:
   vlan20:
     external: true