Messages

It's a bit late, I solved this using the SNI map and a default entry. OpnSense 26.1

Nginx > Data Streamx > SNI Based Routing

default > my openvpn Server

[ein]

private Netzwerke blockieren und bong Netzwerke blockieren bei pppoe0

Ja

Modem vlan01

Wenn Du auf der Opnsense ein Vlan angelegt hast > deaktivieren
Wenn Du auf der Opnsense kein Vlan angelegt hast > aktivieren und Vlan id auf 7 setzen
Bzw. Wenn das Internet schon läuft nicht ändern;-)

Welches Netz haben denn die OpenVPN Clients und wohin wird das geroutet? Zum OpenVPN-Server? Welche IP hat der? Was für ein Netz ist 192.168.1.x und wohin wird das geroutet. Ist das Netz 10.130.0.0/20 euer internes Netz für Clients und Server? Welche IP haben die Mailserver?

Nimm gerne andere IP Adressen als eure orginalen, aber um Tipps geben zu können müssen die IP-Adressen zumindest die Struktur abbilden

edit: TAP-Device, also "enden" die Clients direkt im am OpenVPN-Server angeschlossenen Netz. Was für IP's bekommen dann die Clients? Was meinst Du mit virtuelle?

Korrekt. Ganz safe wären 1488.

Nein, das ist eben nicht notwendig,zumindest nicht in Deutschland. 1492 ist safe . Für dein Gutes HowTo, welches nicht nur für D. gilt mag das allerdings anders sein.

sonst die virtio-Karte auch auf 1500 Bytes plus VLAN beschränkt ist, nämlich als Antwort hierauf:

Was vollkommen ok ist. Auch aus einer virtuellen Maschine funktioniert damit PPPoE und die Anmeldung über ein dsl Modem.... Wichtig ist, dass das PPPoE Interface eine MTU von 1492 hat.

Wenn wir schon spitzfindig werden:

stimmt das spätestens nicht mehr, wenn man dann QinQ macht, das ist nämlich NICHT einkalkuliert.

Klar, es kann funktionieren, weil manche moderne Netzwerkhardware sogar Frames bis 9014 Bytes unterstützt, ich habe das aber im Guide so beschrieben, dass es IMMER funktioniert (gesetzt den Fall, dass Mini-Jumbo-Frames auf der ISP-Strecke auch gehen).

Das macht überhaupt nichts, die meiste Netzwerkhardware ist durchaus in der Lage neue Header  mitaufzunehmen und die Framegröße entsprechend anzupassen. Ja, nicht alle aber selbst alte Switche können das. Qinq ist da keine Ausnahme.

Ein Jumboframe ist der Payload. Die Header werden, soweit ich weiß nicht mitgezählt. Selbst wenn Du 28 vLAN Header hinzufügen würdest, so lange die MTU 1500 beträgt ist es technisch kein Jumboframe

Ich verstehe deine Intention, dass ist für dein HowTo durchaus sinnvoll, aber ist inzwischen eher anders herum. Die meiste Hardware unterstützt dass, nur wenige Komponenten können das nicht.

Ja, ich weiß. :-) Ich habe es aber (das war auch lange vor vlans) auch mal mit den jeweiligen OSI Headern und dem dazugeghörigen Payload gelernt... Da weiß ich manchmal nicht wie ich das nennen soll...

Zumindest MPLS wird auch draußen dran gehängt und wird eigentlich auf den Endpunkten so konfiguriert, dass die MTU auch wieder 1500 betragen kann

Genau, natürlich gibt es eine Maximalgröße des gesamten Pakets. Diese ist bei der Verwendung von vLAN aber normalerweise um den vLAN-Header ergänzt (dann 1518) damit der Payload weiterhin 1500 Byte groß sein kann. Das gilt dann auch noch nicht als Jumboframe.... Und, ja. stimmt. MTU ungleich Payload.... :-)

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header "Teil" des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 "Teil" des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

Exklusiv oder nicht, das ändert nichts daran, dass bei virtualisierten NICs die MTU auf dem PVE-Host bereits vergrößert werden muss, ehe die OpnSense VM das auch nutzen kann.

Das habe ich jetzt schon ein paar mal gelesen und das ist aus meiner Sicht falsch. Die MTU und die Größe des Ethernetframes haben nur bedingt etwas miteinander zu tun. Die MTU gehört zum Layer3 Header des Paketes. Der VLAN Header befindet sich vor dem Layer 3 Header im Layer2 des Paketes. Dieser hat mit der MTU überhaupt nichts zu tun.
Die MTU kleiner machen, damit das gesamte Paket unter einer bestimmten Größe bleibt ist ungefähr so als wenn man ein Ikea-Paket aufteilt ohne zu wissen was die Spedition für einen LKW verwendet. (Was übrigens auch im Bezug zum Ethernetpaket vollkommen egal ist, da sich die Spedition drum kümmert und nicht das Ikea-Paket!!!)

Ja, aber, die einzige Situation, wo das typischerweise relevant ist, ist im DNS Fall, wenn es für einen Namen Einträge für all diese Adresstypen gibt.

Es ist doch insgesamt relevant wenn mit ULAs gearbeitet wird? Wenn ein interner Dienst (DNS, sonst irgendeiner) eine ULA und eine IPv4 hat, wird der IP-Stack des anfragenden Clients beim Neuaufbau der Verbindung den Aufbau über IPv4 bevorzugen.
Für ausgehende Verbindungen in das Internet. Der Client wird bei AAAA und A Records die IPv4 des Zielsystems benutzen. Wenn jetzt der Server im Internet nur einen AAAA Record hat, wird der Client mit seiner ULA bis zum DefaultGateway kommen....

Wenn intern Wenn man also mit ULA's arbeitet um das Problem mit dynamischen Prefixen zu umgehen, muss man halt entsprechend aufpassen. Andersherum kann man aber von der externen öffentlichen IPv6 auf die interne ULA NAT machen. Der IP-Stack wechselt die IP Variante nicht.

https://blog.ipspace.net/2022/05/ipv6-ula-made-useless/

Ich bin mir dessen durchaus bewusst. Beruflich verzichte ich auf ULA's und setze auf einen festen Ipv6 Prefix. Wenn ich aber privat Dienste freigeben möchte (DynDNS) und auch IPv6 filtern möchte, habe ich kaum eine andere Chance. Dynamische Prefixe sind mindestens genauso großer Mist wie ULAs. Ein fester IPv6 Prefix ist mir privat dann zu teuer....

ULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).

Genau aus dem Grund benutze ich ULA auch und hatte schon ein paar Merkwürdigkeiten mit IPv4 und den ULA,s die sich jetzt erklären

Mal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.

Undefiniert ist das nicht, sondern beruht auf der Prio des jeweiligen Stacks des Betriebssystems. Es wird ipv6 bevorzugt.

Da gehts aber nur um die DNS Auflösung, wenn ein Name IPv6 GUA, IPV4 und IPv6 ULA hat, dann wird der Name in der Priorität aufgelöst bzw. vom Client in der Priorität benutzt.
Ist aber für DNS Infrastruktur kein Problem, DNS Server werden dem Client per IP mitgeteilt, dementsprechend ist IPv6 ULA zumindest dafür eine valide Lösung.

Ich will ja garnicht unbedingt klugscheißern, aber Nö. Wie meyergru auch schon schrieb, geht es um die grundsätzliche Priorisierung der Nutzung der entrsprechenden IP-Adresse durch den Netzwerkstack. IPv6 > IPv4 > IPv6 ULA. Das wirkt sich dann natürlich auf die Nutzung der vom DNS-Server zurückgelieferten IP aus.Diese wird vom Stack dann in der Priorität genutzt. Das gilt, wenn der Client sowohl ULA, GUA und IPv4 hat,auch für die IP-Adresse des DNS-Servers und damit für die Namensauflösung.
Der DNS-Infrastruktur ist das egal, ja.

weil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.

Das war mir bisher tatsächlich neu, danke dafür!

Egal mit welchem Modem (so lange die entsprechende DSL Technik unterstützt wird) und auch egal mit welcher Firmware ....

Da hab ich z.B. mit dem Vigor 167 andere Erfahrungen. Neu geliefert, keine Verbindung. Aktuelle Firmware rein ohne irgendeine Änderung der Konfiguration - läuft.

Spannend! Ich habe mit dem 165 andere Erfahrungen gemacht. Die Konfiguration war in den alten Firmwareversionen für den Arsch,gerade der Bridgemodus. Aber es ging