Homelab Rebuild Part 5: The First VLAN

Why telephony of all things Link to heading

After part 4 everything is in place: a firewall that can enforce rules, and a host for services. Now comes the first VLAN of my own — and I deliberately started with the case where the least can go wrong.

If the landline dies, it doesn’t matter. I have a Swiss phone and a German phone. A networking experiment whose worst outcome is that one handset doesn’t ring is the ideal first test. That was the selection logic: not the most important service first, the most harmless one.

On top of that, telephony has a very clear communication profile. A phone talks to the phone system, the system talks to its providers. Nobody else. That makes it a clean candidate for its own network.

Why a phone system at all Link to heading

Before this, a DECT base station sat directly in the network and talked to the providers itself. Two things bothered me about that.

The device can reach everything and talk straight to the internet. A consumer device with opaque firmware sitting in the same network as the NAS and the workstation — exactly the pattern from part 1 that I wanted rid of.

And I had to pick the line every single time. I’m German-Swiss and need both: a German number and a Swiss one. Calls from Germany to Switzerland and back are outrageously expensive if you pick the wrong line. So I had to think about it before every call.

With my own system, the software decides. I dial +49... or +41... and the dialplan picks the matching trunk. Two trunks, one Swiss, one German, routed by country code.

That’s the real gain: something I had to remember becomes a rule that always applies.

The system Link to heading

Asterisk 22 LTS on Debian, as a VM on the Proxmox host — following the rule from part 4: anything that talks to the internet gets a VM.

One detail you trip over: Debian 12, not 13. Sangoma’s package feed supports bookworm, and I wanted neither to compile it myself nor to use the possibly outdated version from the distribution repos. Not a pretty justification, but an honest one: the distribution follows the feed, not the other way round.

Two outbound trunks over PJSIP, two internal extensions — a softphone on the desktop and the DECT base. Plus separate identify blocks so that inbound calls get attributed to the right trunk.

The dialplan covers both dialling formats, +41... and 0041..., because different devices dial differently: the softphone uses the plus sign, other devices the double zero. Configure only one variant and you’ll have one phone that works and one that doesn’t — and you’ll go looking for the fault in your network config.

Building the VLAN Link to heading

Three places have to line up.

On the R4, a new VLAN goes into the bridge. Current OpenWrt uses DSA and a VLAN-aware bridge for this, no longer the old swconfig:

uci add network bridge-vlan
uci set network.@bridge-vlan[-1].device='br-lan'
uci set network.@bridge-vlan[-1].vlan='30'
uci add_list network.@bridge-vlan[-1].ports='sfp-wan:t'   # trunk to the OPNsense
uci add_list network.@bridge-vlan[-1].ports='lan1:t'      # trunk to the Proxmox host
uci add_list network.@bridge-vlan[-1].ports='lan3:u*'     # phone, access port

:t means tagged, :u* untagged and native for that port. And of course with the failsafe timer from part 3 — this is exactly what it’s for.

On the OPNsense, a VLAN interface with tag 30 on the LAN interface, address 10.0.30.1/24, its own DHCP range.

On the Proxmox host, the Asterisk VM’s virtual NIC gets the VLAN tag directly on the device. Nothing to configure inside the guest — the VM just notices it’s suddenly in a different network.

What went wrong Link to heading

Now the part that actually cost time. Four problems that all had the same symptom — something isn’t reachable — and four completely different causes.

The port in two native VLANs Link to heading

The phone sat on its access port and stubbornly kept its old address from the old network. The port was still listed in the old VLAN’s port list as well, also untagged.

A port can’t be native in two VLANs at once. When you move it you have to remove it from the old list explicitly — adding it to the new one isn’t enough. Obvious once you know it, completely invisible until you do.

The VM with two addresses Link to heading

After setting the VLAN tag, the Asterisk VM suddenly had two IPv4 addresses at once — the old one and the new one. A dhclient -r had failed and the old address stayed stuck on the interface.

Fixed with:

ip addr flush dev ens18
dhclient ens18

This is the kind of fault that’s easy to miss while debugging, because ping works. Just from the wrong source address.

The phone with the stale server address Link to heading

“Line forbidden” on the display. I suspected the firewall first, then the VLAN, then the Asterisk config.

The phone’s web interface still had the old IP address of the phone system as its SIP server. The system had moved, after all. Once corrected, it registered immediately.

The interface list on the DHCP server Link to heading

A new interface doesn’t automatically mean the DHCP server answers on it. The new interface has to appear explicitly in the service’s interface list. Easy to forget and a debugging detour of its own.

And two from the telephony side Link to heading

One registration was stubbornly rejected even though the config was right. Fixed by a full restart of Asterisk — a reload wasn’t enough.

And one failed call where I spent a long time suspecting a missing SIP header. The actual cause was a typo in the dialled number, which had given it a duplicated country code. The lesson: check what’s actually going over the line before you start debugging headers.

The consequence: static reservations Link to heading

After that afternoon, the phone system and the handset both have fixed reservations in the firewall. Not out of tidiness, but because half the problems came from addresses changing without me noticing.

And since this was already the reason for two reinstalls back in part 3: reservations hang off MAC addresses, and anything that creates a new MAC breaks them.

The firewall rules Link to heading

The VLAN is up and layer 2 separation works. For testing I’d started with a rule that let everything through — sensible for checking whether telephony works at all, but that makes the VLAN a separate network and not yet a security boundary.

Tightening it takes four rules, and the order is the whole trick:

Rule 3 catches everything internal before rule 4 lets the rest through. And rules 1 and 2 sit in front because the firewall itself has a private address — otherwise rule 3 would block DNS and time along with it.

What I deliberately did not do: restrict the rules to the specific SIP and RTP ports of the two providers. With many providers the media streams come from different servers than the signalling, and the address ranges change. A rule that silently breaks calls six months from now is worse than a slightly broader one that holds.

The real gain sits in rule 3 anyway: the phone and the phone system can no longer reach the NAS, the workstation or the Proxmox host. That was the goal. Being allowed out to the internet is something they need.

Traffic between the phone and the system stays inside the VLAN and goes over the switch — the rules don’t touch that, the firewall isn’t involved at all.

Effort Link to heading

A few hours one evening, including every dead end described above. The Asterisk configuration is the demanding part and isn’t self-explanatory — PJSIP endpoints, trunks, dialplan syntax. The networking around it was comparatively quick.

Next up Link to heading

A VLAN you assign to a port by hand works fine for a phone on a cable. For Wi-Fi devices it doesn’t — there’s no port to assign anything to.

So the next part brings the answer to that: 802.1X with FreeRADIUS, a single SSID, and the network deciding per device where it lands.

Part of a series about rebuilding my home network. As of August 2026. Questions, corrections and your own experiences are welcome in the comments.