Messages

Ich wiederhole hier also nochmal dass es hierfür (enterprise) Switch features wie Auto-Voice-VLAN gibt. Man kann das halt nicht mit jedem Wald und Wiesen switch machen.

Cedrik meine "Wald und Wiesen Switche" sind Juniper. Dort gibt es eine "Port Rule" die heißt "Desktop and Phone" diese hatte ich schon vorher gesetzt. Leider mit dem genannten Ergebnis.

@Bode
"Ingressfilter für MAC-Adressen auf den Switches" alleine reichen nicht. An Switch-Ports, an denen kein Telefon angeschlossen ist, darf auch kein VLAN 10-Egress stattfinden. Wie Du das konfigurierst ist herstellerabhängig, da gibt es unterschiedliche Lösungen.

Guter Einwand. Ich lese und probiere, wie das praktisch umgesetzt werden kann.
Danke für eure Hilfe.

@Maurice
Richtig, das sind valide Argumente. Ich muss mich belesen, wie ich das Ingressfilter für MAC-Adressen auf den Switchen setzen kann. Eine Idee ist, allen MAC-Adressen die keine Telefone sind, über das Filter das Vlan1 und umgedreht den Telefonen vlan10 zuzuweisen auf dem Switch.
Danke dir für den Denkanstoß. Manchmal sieht man den Wald vor lauter Bäumen nicht.

@Cedrik
Die Scopeid wird unter Windows anscheinend herausgefiltert.
Ich kann nur Windows beurteilen, da dort das Problem auftritt. Leider kann ich Linux im Moment nicht testen.
Die Telefone sind wie beschrieben mit IPv6 und IPv4 konfiguriert und funktionieren ohne Probleme.
Vielen Dank.

Grüße Bode

Ich denke der trunk zur OPNsense ist nicht /nur/ getagged, sondern hat auch ein ungetaggtes VLAN laufen:

https://docs.opnsense.org/manual/how-tos/vlan_and_lagg.html

Bitte genau so umsetzen, andernfalls kommt es zu den Effekten die in der "Attention" box beschrieben sind.

Vielen Dank für den Hinweis, ist genauso umgesetzt.

Vielleicht lassen sich die IP-Telefone so konfigurieren, dass sie das VoIP-VLAN nicht an ihren zweiten Port (an dem der PC hängt) durchreichen? Wäre ein naheliegendes Feature, denn genau für deinen Use Case haben diese ja den zweiten Port.

Du solltest jedenfalls nicht versuchen, für ein Layer 2-Problem (nicht sauber getrennte VLANs) einen Workaround auf höheren Layern (z. B. Router Advertisements) zu basteln.

@Patrick Je nach NIC / Treiber / Konfiguration wird das VLAN-Tag ggfs. ignoriert und Windows akzeptiert dann alle Frames. So kommt es zur Vermischung von VLANs. Habe ich auch schon gesehen.

Genauso wie du es beschreibst ist es. Windows ignoriert die VLAN-Tags.
Ich möchte nicht an dem Layer2 Problem herumdoktern. Habe ewig gesucht woran es liegen könnte. Ich möchte eine Lösung, womit die PC's ohne Konfiguration in ihr vlan kommen, unabhängig ob ein Telefon davor ist oder nicht, den Telefonen ihr vlan zugewiesen wird und die PC's mobil mit ihrer Netzwerkkarte benutzt werden können. Damit ist es für meine Konfiguration das einfachste auf der Opnsense eine Netzwerkkarte oder zusätzliches Lagg zu installieren und dieser Konfig das Telefon-Vlan zu zuweisen.  Damit wären alle meine Bedingungen erfüllt. Laut RFC 4861 ist der Link Local des Routers dann ein anderer und so sollte alles funktionieren. Ist zwar nicht schön, macht aber den kleinsten Aufwand und gibt mir die notwendige Unabhängigkeit. Ich werde es einmal vorbereiten und eine Rückmeldung geben.

Schöner wäre es, man könnte jedem vlan auf dem lagg eine eigene Link Local Adresse zuweisen. Das gibt die RFC aber nicht her.

Vielen Dank für eure Rückmeldungen und Hinweise.

Grüße Bode

Mit Paket-Trace gucken, was da passiert. Keine Ahnung. Ich würde immer empfehlen, tagged und untagged nicht zu mischen auf der OPNsense. Also vielleicht von der OPNsense bis zum Switch beide VLANs tagged betreiben, und dann erst am Switch das VLAN 1 für den PC wieder auf untagged setzen.

Das lagg ist mit allen vlans tagged zum Switch. Das Problem sind die fehlenden Ports in den Zielräumen. Ich wollte VOIP-Telefone vor den PC's betreiben. Das funktioniert mit ipv4, aber nicht mit ipv6, da die Einstellungen per Multicast von der Opnsense per Routeradvertisement auf den PC gepusht werden und beide Vlans auf dem Switchport liegen.

Das hört sich nach einer inkorrekten VLAN-Konfiguration des PCs an. Dort muss die NIC so konfiguriert werden, dass das VoIP-VLAN ignoriert wird.

Das ist ggfs. einfacher, wenn Du auf dem Switch-Port beide VLANs taggst und auf dem PC explizit das gewünschte VLAN (tagged) konfigurierst.

Mit IPv6 und OPNsense hat das alles relativ wenig zu tun - Du hast ein Layer 2-Problem zwischen Switch und Client-PC.

Grüße
Maurice

Ja, das wäre eine Lösung, wenn die PC's nicht mobil wären, könnte ich einfach den Switchport tagged auf vlan1 und die Netzwerkkarte auf vlan1 setzen. Da diese aber mobil sind, fällt diese Lösung aus.

IPv6 Router Advertisements müssen laut RFC 4861:
-von der Link Local des Routers kommen
-mit der MAC des Parent Interfaces gesendet werden
-per Multicast an ff02::1 gehen

Wenn mehrere VLANs auf demselben Parent liegen, sieht Windows:
-dieselbe MAC
-dieselbe Link Local
-denselben Router
→ und akzeptiert alle RAs.

Lösung: VLANs auf OPNsense NICHT über denselben Parent führen
Statt:
lagg0.1
lagg0.10

z.B.:
em0.1
em1.10

oder:

lagg0 für Daten
lagg1 für VOIP

Ich weiß bloß nicht, ob das dann sauber funktoniert. Damit könnte ich die Switchkonfiguration und die PC's unverändert verwenden.

Vielen Dank euch beiden!

Grüße Bode

Verstehe ich nicht. Betreibst du mehrere VLANs untagged auf ein und demselben Port?

Nein,

PC (untagged vlan1)<-->VOIP-Telefon mit zwei Ethernetports (vlan10 tagged)<--->Switch (z.B. Port5 vlan1 untagged, vlan10 tagged)

Egal ob nur der PC oder der PC mit Telefon angeschlossen sind, es werden die Route, der DNS-Server und die Domänesuchliste IPv6 vom vlan10 auf dem PC im vlan1 gesetzt.

Entschuldige Patrick, mein Fehler.

In meinem Fall ist das grundsätzliche Problem, dass ich zu wenige Ports in den Zielräumen habe.
Nach dem Studium von NDP gibt es drei Lösungen für das Problem.

Lösungen:
a) Jedes Telefon bekommt einen eigenen Port auf dem Switch mit der Zuweisung des vlans (nicht möglich bei mir).
b) Ich setze auf der opnsense eine extra Netzwerkkarte oder lagg1.vlan10 auf.
c) Abschaltung von ipv6 auf vlan10.

Ich würde jetzt Lösung b) umsetzen wollen.
Könnt ihr das so bestätigen?

[Voraussetzungen:]

Hallo,

ich habe ein Problem mit gleichen ULA-Adressen auf lagg.vlans, die nur durch die Zonenbezeichner zu unterscheiden sind.

Voraussetzungen:
-opnsense mit aktuellem Patchstand
-opnsense mit lagg.vlan1 und lagg.vlan10 im Lan
-Switch (Port1 +Port2) mit Trunk zu opnsense (Port1 +Port2)
-auf dem Switch eine Port-Konfiguration z.B. Port 5 mit lagg.vlan1 (native PC) und lagg.vlan10 (trunk VOIP)

Ziel:
-lagg.vlan1 soll die Konfiguration route + dns bekommen, dies funktioniert
-lagg.vlan10 soll die Konfiguration nur für voip-Telefone bekommen (über lldp-med, dhcp-option), dies funktioniert

Problem:
Alle lagg.vlan haben die gleiche ULA fe80::xxx:xxxx:xxxx:wxyz.
Windowsclients ignorieren die Zonenbezeichner der Router-ULA und bekommen anhand dieser ULA über das routeradvertisement die ipv6 Einstellungen für:
lagg.vlan1 -richtig
und
lagg.vlan10 -falsch

Fragen:
Wie bekomme ich verschiedene ULA für die verschiedenen lagg.vlans, damit die lagg.vlan10 Einstellungen nicht auf dem Client gesetzt werden?
Gibt es eine andere saubere Lösung?
Warum werden nicht gleich verschiedene ULA pro vlan erzeugt?

Vielen Dank an die Entwickler für das Produkt.

Grüße Bode


 

Hallo Monviech,

vielen Dank für den Denkanstoß.

Grüße Bode

Hallo,

ich habe ein Problem mit einer neuen IPSecV2-Verbindung bei der die "Automatically generated rules (end of ruleset)" nicht erstellt werden.

Egal ob im neuen "VPN: IPsec: Verbindungen"  oder unter "Tunnel Settings [legacy]", wenn ich die Verbindung aktiviere werden die Firewallregeln nicht automatisch erstellt.

Hintergrund ist, ich möchte eine IPSecV1 Verbindung zum gleichen Ziel ersetzen.
Dort werden bei der Aktivierung die Firewallrules erstellt.

Frage: Wie kann ich die Erstellung der "Automatically generated rules (end of ruleset)" für diese neue Verbindung erzwingen oder debuggen?

Vielen Dank für eure Hilfe.

Grüße Bode

Hallo,

nach dem Upgrade auf die letzte Version "OPNsense 23.7-amd64" muss beim Export einer ovpn-Benutzerkonfiguration die Option

Code Select Expand


auth-user-pass

unter Clientexport/Custom Config händisch vor dem Export hinzugefügt werden.
Ist dies so gewollt oder ist dies ein Softwarefehler?

Ich stelle die Frage, da bei den vorherigen Versionen, diese Option immer durch den Export hinzugefügt wurde.
Vielen Dank für eure Arbeit!

Hallo,

nach dem Update 22.7.4 sind in der Webgui unter "Dienste/ACME Client" alle Einstellungen weg und die Zertifikate werden nicht angezeigt.
Unter "/var/etc/acme-client" ist alles noch vorhanden.
Ein Backup der Einstellungen ist vorhanden.
Das Upgrade auf 22.7.6 war erfolgreich, aber im "ACME-Client" keine Änderung.
Auch eine Wiederherstellung vom Backup zeigt keinen Erfolg.

Wie bekomme ich die Einstellungen und Zertifikate wieder in die Webgui?

Vielen Dank für eure Hilfe.

Update: Einfach den Button "Issuse/Renew All Certificates" betätigt.

Had the same issue with dns-root.de

Hallo

@micneu, @goodomens42 und @pmhausen vielen Dank für eure Antworten.

@goodomens42 und @pmhausen
Ist gelöst, die einzelnen IP-Endadressen für die Endpoints waren
Endpoint1=10.0.0.10/32,2003:x:x:x::10/128 und
Endpoint2=10.0.0.11/32,2003:x:x:x::11/128.

Nachdem ich diese auf
Endpoint1=10.0.0.10/32,2003:x:x:x::10/128 und
Endpoint2=10.0.0.18/32,2003:x:x:x::18/128 geändert habe
und der Hinweis mit den Subnetmask/Präfix =32/128 brachten letztendlich den Erfolg.

Was ich nicht verstehe, dass bei der Subnetmask /32 und Präfix /128 sind jeweils nur eine IP zugelassen, warum es mit den IP-Endadressen 10 und 11 nicht funktioniert?

Danke.

[Wireguardserver]

Hallo

@micneu und @goodomens42 vielen Dank für eure Antworten.

@godsman das Ändern der Subnetmask ipv4 und des Präfix ipv6 ändert nichts.
Nach Neustart habe ich den gleichen Fehler.

@micneu
Wireguardserver mit
1x ipv4         und      1x ipv6
10.0.0.1/24                    2003:x:x:x::1/64
    |                                   |
    | _________________|
                     |             |__________________   
                     |                                                  |
                Endpoint 1                                       |
10.0.0.10/24 und 2003:x:x:x::10/64               |
                                                                        |
                                                                     Endpoint2
                                                     10.0.0.11/24 und 2003:x:x:x::11/64


Wenn die Konfiguration mit zwei Endpoints eingerichtet ist, der Wireguardserver neu gestartet wird,
bekommt der Endpoint1 im Karteireiter "List Configuration" allowed ips: (none), dort sollte aber stehen

10.0.0.0/24, 2003:x:x:x::/64

Ich hoffe so ist es ersichtlich.

Nehme ich die Konfiguration nur mit ipv4 vor funktioniert es für beide Endpoints.

Gestern hatte ich einen Bericht vom Server gesendet. Dort wurde ein php wireguard api Fehler mit der Adresszuweisung ausgegeben.
Sieht so aus, als wäre es ein Softwarefehler.

[einen]

Hallo,
ich habe einen eigenartigen Fehler mit wireguard:

Richte ich einen Endpoint mit erlaubter ipv4-(x.x.x.10) und ipv6-(x:x:x:x::10) ein funktioniert alles.
Richte ich einen zweiten Endpoint mit erlaubter ipv4-ipv4-(x.x.x.11) und ipv6-(x:x:x:x::11) ein, bekommt nur der zweite Endpoint die erlaubten ipv4- und ipv6-Adressbreiche auf dem Server unter List Configuration. Im Anhang die entsprechenden Screenshots.
Ist dieser Fehler bekannt und kann dieser auf anderen Systemen nachvollzogen werden?
Kann ich diesen Fehler umgehen?

Vielen Dank für eure Hilfe!