Homelab-Umbau Teil 5: Das erste VLAN

Warum ausgerechnet Telefonie Link zu Überschrift

Nach Teil 4 steht alles bereit: eine Firewall, die Regeln durchsetzen kann, und ein Host für Dienste. Jetzt kommt das erste eigene VLAN — und ich fange bewusst mit dem Fall an, bei dem am wenigsten kaputtgehen kann.

Wenn das Festnetz ausfällt, ist es egal. Ich habe ein Schweizer und ein deutsches Handy. Ein Netzwerkexperiment, das im schlimmsten Fall dazu führt, dass ein Telefon nicht klingelt, ist der ideale erste Testfall. Genau das war die Auswahllogik: nicht der wichtigste Dienst zuerst, sondern der harmloseste.

Dazu kommt, dass Telefonie ein sehr klares Kommunikationsprofil hat. Ein Telefon redet mit der Telefonanlage, die Anlage redet mit ihren Anbietern. Sonst mit niemandem. Das macht es zum sauberen Kandidaten für ein eigenes Netz.

Warum überhaupt eine eigene Telefonanlage Link zu Überschrift

Vorher hing eine DECT-Basisstation direkt im Netz und sprach selbst mit den Anbietern. Zwei Dinge haben mich daran gestört.

Das Gerät kann alles erreichen und direkt ins Internet. Ein Consumer-Gerät mit undurchsichtiger Firmware, das mit dem NAS und der Workstation im selben Netz steht — genau das Muster aus Teil 1, das ich loswerden wollte.

Und ich musste jedes Mal die Leitung auswählen. Ich bin Deutsch-Schweizer und brauche beides: eine deutsche und eine Schweizer Nummer. Anrufe von Deutschland in die Schweiz und zurück sind unverschämt teuer, wenn man die falsche Leitung nimmt. Also musste ich vor jedem Anruf daran denken.

Mit einer eigenen Anlage entscheidet das die Software. Ich wähle +49... oder +41..., und der Dialplan sucht die passende Leitung raus. Zwei Trunks, einer für die Schweiz, einer für Deutschland, Routing nach Ländervorwahl.

Das ist der eigentliche Gewinn: Aus einer Sache, an die ich denken musste, wird eine Regel, die immer gilt.

Die Anlage Link zu Überschrift

Asterisk 22 LTS auf Debian, als VM auf dem Proxmox-Host — nach der Regel aus Teil 4: Wer mit dem Internet spricht, kriegt eine VM.

Ein Detail, über das man stolpert: Debian 12, nicht 13. Der Paket-Feed von Sangoma unterstützt bookworm, und ich wollte weder selbst kompilieren noch die möglicherweise veraltete Version aus den Distributionsquellen. Das ist keine schöne Begründung, aber eine ehrliche: Die Distribution richtet sich nach dem Feed, nicht umgekehrt.

Zwei ausgehende Trunks über PJSIP, zwei interne Nebenstellen — ein Softphone am Rechner und die DECT-Basis. Dazu jeweils eigene identify-Blöcke, damit eingehende Anrufe dem richtigen Trunk zugeordnet werden.

Der Dialplan deckt beide Wählformate ab, +41... und 0041..., weil verschiedene Geräte unterschiedlich wählen: Das Softphone nutzt das Pluszeichen, andere Geräte die Doppelnull. Wer nur eine Variante konfiguriert, hat ein Telefon, das funktioniert, und eines, das nicht funktioniert — und sucht den Fehler in der Netzwerkkonfiguration.

Das VLAN bauen Link zu Überschrift

Drei Stellen müssen zusammenpassen.

Auf dem R4 kommt ein neues VLAN in die Bridge. Der aktuelle OpenWrt nutzt dafür DSA und eine VLAN-aware Bridge, nicht mehr das alte 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 zur OPNsense
uci add_list network.@bridge-vlan[-1].ports='lan1:t'      # Trunk zum Proxmox-Host
uci add_list network.@bridge-vlan[-1].ports='lan3:u*'     # Telefon, Access-Port

Das :t bedeutet tagged, :u* untagged und als natives VLAN des Ports. Und natürlich mit dem Failsafe-Timer aus Teil 3 — für genau solche Änderungen ist er da.

Auf der OPNsense ein VLAN-Interface mit Tag 30 auf dem LAN-Interface, Adresse 10.0.30.1/24, eigener DHCP-Bereich.

Auf dem Proxmox-Host bekommt die virtuelle Netzwerkkarte der Asterisk-VM das VLAN-Tag direkt am Gerät. Im Gastsystem selbst ist nichts zu konfigurieren — die VM merkt nur, dass sie plötzlich in einem anderen Netz steht.

Was schiefging Link zu Überschrift

Und jetzt der Teil, der wirklich Zeit gekostet hat. Vier Probleme, die alle dasselbe Symptom hatten — irgendwas ist nicht erreichbar — und vier völlig verschiedene Ursachen.

Der Port in zwei nativen VLANs Link zu Überschrift

Das Telefon hing an seinem Access-Port und behielt hartnäckig seine alte Adresse aus dem alten Netz. Der Port stand noch gleichzeitig in der Portliste des alten VLANs, ebenfalls untagged.

Ein Port kann nicht in zwei nativen VLANs gleichzeitig sein. Man muss ihn beim Umzug in der alten Liste explizit entfernen — es reicht nicht, ihn der neuen hinzuzufügen. Das ist offensichtlich, sobald man es weiss, und völlig unsichtbar, solange man es nicht weiss.

Die VM mit zwei Adressen Link zu Überschrift

Nach dem Setzen des VLAN-Tags hatte die Asterisk-VM plötzlich zwei IPv4-Adressen gleichzeitig — die alte und die neue. Ein dhclient -r war fehlgeschlagen, die alte Adresse blieb am Interface kleben.

Behoben mit:

ip addr flush dev ens18
dhclient ens18

Das ist die Art Fehler, die man beim Debuggen leicht übersieht, weil ping funktioniert. Nur eben von der falschen Absenderadresse aus.

Das Telefon mit der alten Server-Adresse Link zu Überschrift

“Linie verboten” auf dem Display. Ich habe erst die Firewall verdächtigt, dann das VLAN, dann die Asterisk-Konfiguration.

Im Webinterface des Telefons stand noch die alte IP-Adresse der Telefonanlage als SIP-Server. Die Anlage war ja umgezogen. Nach der Korrektur registrierte sich das Telefon sofort.

Die Interface-Liste im DHCP-Server Link zu Überschrift

Ein neues Interface heisst nicht automatisch, dass der DHCP-Server darauf antwortet. Das neue Interface muss in der Interface-Liste des Dienstes explizit mit auftauchen. Leicht zu vergessen und ein eigener Debugging-Umweg.

Und zwei aus der Telefonie-Ecke Link zu Überschrift

Eine Registrierung wurde hartnäckig abgelehnt, obwohl die Konfiguration stimmte. Gelöst durch einen kompletten Neustart von Asterisk — ein reload reichte nicht.

Und ein fehlgeschlagener Anruf, bei dem ich lange einen fehlenden SIP-Header verdächtigt habe. Die tatsächliche Ursache war ein Tippfehler in der gewählten Nummer, die dadurch eine doppelte Vorwahl hatte. Die Lehre: Erst prüfen, was tatsächlich über die Leitung geht, bevor man Header debuggt.

Die Konsequenz: statische Reservierungen Link zu Überschrift

Nach diesem Nachmittag haben Telefonanlage und Telefon feste Reservierungen in der Firewall. Nicht aus Ordnungsliebe, sondern weil die Hälfte der Probleme daher kam, dass sich Adressen geändert haben, ohne dass ich es mitbekommen habe.

Und weil das schon in Teil 3 der Grund für zwei Neuinstallationen war: Reservierungen hängen an MAC-Adressen, und alles, was eine neue MAC erzeugt, bricht sie.

Die Firewall-Regeln Link zu Überschrift

Das VLAN steht, die Trennung auf Layer 2 funktioniert. Für den Test hatte ich erstmal eine Regel angelegt, die alles durchlässt — sinnvoll, um zu sehen, ob Telefonie überhaupt läuft, aber damit ist das VLAN eben nur ein eigenes Netz und noch keine Sicherheitsgrenze.

Die Verengung besteht aus vier Regeln, und die Reihenfolge ist der ganze Trick:

Regel 3 fängt alles Interne ab, bevor Regel 4 pauschal durchlässt. Und Regel 1 und 2 stehen davor, weil die Firewall selbst eine private Adresse hat — sonst würde Regel 3 auch DNS und Zeit mitsperren.

Was ich bewusst nicht gemacht habe: die Regeln auf konkrete SIP- und RTP-Ports der beiden Anbieter einschränken. Medienströme kommen bei vielen Anbietern von anderen Servern als die Signalisierung, und die Adressbereiche ändern sich. Eine Regel, die nach einem halben Jahr stillschweigend Gespräche zerlegt, ist schlechter als eine etwas weitere, die trägt.

Der eigentliche Gewinn steckt ohnehin in Regel 3: Telefon und Telefonanlage kommen nicht mehr ans NAS, an die Workstation oder an den Proxmox-Host. Das war das Ziel. Dass sie ins Internet dürfen, müssen sie ja.

Der Verkehr zwischen Telefon und Anlage läuft übrigens innerhalb des VLANs über den Switch — daran ändern die Regeln nichts, dafür ist die Firewall gar nicht zuständig.

Aufwand Link zu Überschrift

Ein paar Stunden an einem Abend, inklusive aller oben beschriebenen Sackgassen. Die Asterisk-Konfiguration ist der aufwendigste Teil und nicht selbsterklärend — PJSIP-Endpunkte, Trunks, Dialplan-Syntax. Das Netzwerk drumherum war vergleichsweise schnell.

Nächster Schritt Link zu Überschrift

Ein VLAN, das man von Hand einem Port zuweist, funktioniert gut für ein Telefon an einem Kabel. Für WLAN-Geräte funktioniert es nicht — da gibt es keinen Port, dem man etwas zuweisen könnte.

Im nächsten Teil kommt deshalb die Antwort darauf: 802.1X mit FreeRADIUS, eine einzige SSID, und das Netz entscheidet pro Gerät, wo es landet.

Teil einer Serie über den Umbau meines Heimnetzes. Stand: August 2026. Fragen, Korrekturen und eigene Erfahrungen gerne in die Kommentare.