Messages

91

German - Deutsch / Re: VXLAN in der OPNsense verstehen

« on: May 12, 2022, 08:24:57 am »

Danke für deine Erläuterung. Das Vorgehen leuchtet ein. Werde ich so erstmal zwischen zwei sensen ausprobieren und dann versuchen es an unsere Switche zu connecten.

Schlussfolgern lässt sich aus dem Vorgehen jedenfalls, dass man weder VLAN-TAGS noch QinQ-Tags in einen VTEP schicken kann, da die Bridge nicht in der Lage ist Tags zwischen den hinzugefügten Interfaces übertragen.

92

German - Deutsch / VXLAN in der OPNsense verstehen

« on: May 10, 2022, 03:02:55 pm »

Hallo zusammen,

ich versuche gerade VXLAN in der OPNsense zu verstehen. Die Doku hilft da aktuell leider nicht weiter, das Forum ist da auch noch nicht sonderlich hilfreich.

Punkt 1 (Tunneling von VLANs / QinQ)

VXLAN heißt, Layer2 über ein Layer 3 Netz tunneln zu können.  Die Tunnelendpunkte (TEPs) können Point to Point- (Unicast) oder Point to Multipoint-Verbindungen (Multicast) aufbauen.

Eine Tunnelendpunkt kann 16.777.215 VNIs (VXLAN Network Identifiers) unterscheiden. Jedes VNI bildet dabei ein eigenes Layer2-Netz. Und in jedes VNI können vollwertige Layer2 Frames gekapselt und an einen anderen TEP geschickt geschickt werden.

Daraus folgt:

Jedes VNI kann untagged Frames transportieren, aber auch genauso gut VLAN-getaggte Frames und auch QinQ-getaggte Frames. Theoretisch wären so 16.777.215 (VNI) * 4094 (Outer Q) * 4094 (Inner Q) unabhängige Layer 2-Netze mit nur einem VXLAN-Netzwerk tunnelbar.

Nun lassen aber viele Netzwerkgeräte nur zu, durch ein VNI ungetaggte Layer 2 Frames zu schicken. Bei solchen Geräten kann man dann immer nur ein VLAN je VNI übertragen. Es wird also bspw. auf Switch A VLAN 100 ungetagged in den TEP mit der VNI 100 geschickt. Auf Switch B kommt dann VNI 100 an und wird dort in ein VLAN ausgekapselt. Auf Switch B muss VNI 100 aber nicht zwingend auf VLAN 100 ausgekapselt werden, man kann es auch z.B. auf VLAN 111 auskapseln.

Der Nachteil dieses Vorgehens ist, dass man für jedes VLAN ein eigenes VNI konfigurieren muss. Der Aufwand dafür ist ggf. recht groß.

Manche Netzwerkgeräte lassen es aber auch zu, dass man VLAN oder QinQ getaggte Frames durch den VNI schicken kann. Somit braucht man nur noch ein VNI konfigurieren, über das man dann 4094 VLANs schicken kann oder eben bei Einsatz von QinQ 4094x4094 VLANs.

Ich hab noch nicht so richtig raus, was die OPNsense kann. Ist beides möglich? Wenn ja, wie? Wenn nein, was ist möglich?

Punkt 2 (untagged, VLAN oder QinQ-Interface an VXLAN binden)

Ein VXLAN-Interface mit einem VNI anzulegen scheint mir jetzt nicht so die Hürde zu sein. Das ist unter Interfaces - Other Types - VXLAN schnell gemacht. Das VXLAN-Interface ist nach der Erstellung verüfgbar um assigned zu werden.

Ich bin mir aber noch nicht sicher, wie ich nun ein Layer2-Netz an ein VNI binde. Verbinde ich ein untagged- / VLAN- / QinQ-Device per Bridging auf das VXLAN device oder wie geht man vor? Und muss man das VLAN/QinQ Device speziell konfigurieren, dass es Layer2-Taffic aufnimmt und an den Tunnel weiter reicht?

Punkt 3 (Standard?)

Hält sich das VXLAN in der OPNsense an RFC7348? Kann ich die OPNsense mit jedem VXLAN-fähigen Netzwerkgerät (Switch, Router, Hypervisor, Server) verbinden welches RFC7348-konform ist? Oder gibts hier irgendwelche Einschränkungen?


Vielen Dank für die Aufklärung.

93

German - Deutsch / Re: Bug bei der Benennung von neuen VLAN-Interfaces?

« on: April 28, 2022, 09:25:25 pm »

Eins noch....


Matured Altinstallationen (also alle, die es vor dem QinQ-Feature gab), die noch mit nic#_vlan#-Notation konfiguriert wurden könnten ja noch ein paar Jährchen überleben. Das muss ja auch im Code weiter berücksichtigt werden. Gibts dazu Infos wie das weiter geht? Oder werden solche Devices unter der Haube einfach irgendwann automatisch auf vlan#### und qinq#### umgestellt?

94

German - Deutsch / Re: Bug bei der Benennung von neuen VLAN-Interfaces?

« on: April 28, 2022, 09:22:33 pm »

Ich versuchs mal ausführlich mit konkreten Beispielen und Verbesserungsvorschlägen. ;-)

Im ersten Moment stört sich an der neuen Notation vor allem das Gewohnheitstier in mir.  Im zweiten Moment und nachdem ich mich damit auseinander gesetzt habe stelle ich fest, dass die meisten Infos zwar da sind, aber eben ziemlich unübersichtlich. Ja, hier gehts um UX. :-)

Zum Menü Assignements:

So siehts aus, wenn man keine Bezeichnung fürs Parent-Interface angegeben hat:

Beispiel 1

Interface            Network port

LAN                   vmx1 ( AA:BB:CC:11:22:33 )
Test-QinQ           qinq01 ( Parent: vlan01, Tag:1000)
Test-VLAN          vlan01 ( Parent: vmx2, Tag:999)
WAN                  vmx0 ( 00:11:22:33:44:55 )

WAN und LAN sowie Test-VLAN sind in Ordnung. Man kann sofort sehen, auf welchem Device das basiert. Bei nur vier Einträgen ist das auch noch kein Problem.
Test-QinQ hat aber nicht alle Informationen enthalten, es fehlt die Info, welche physical NIC darunter steckt. Ich muss also durch die Tabelle springen und das parent-Interface raus suchen, damit ich an den outer Tag komme.

So siehts aus, wenn man das gleiche Setup mit Bezeichnungen (fett) fürs Parent-Device angegeben hat:

Beispiel 2

Interface            Network port

LAN                   vmx1 ( AA:BB:CC:11:22:33 )
Test-QinQ           qinq01  vmx2_vID0999_in1000 ( Parent: vlan01, Tag:1000)
Test-VLAN          vlan01 vmx2_vID0999 ( Parent: vmx2, Tag:999)
WAN                  vmx0 ( 00:11:22:33:44:55 )
 

Jetzt hab ich alle Infos in der Tabelle, sogar in einer Spalte Zeile. Aber auch nur, weil ich es selbst rein geschrieben habe. Und hier steckt auch schon das nächste Problem: Menschen machen Fehler. Ich will mich nicht auf irgendwelche Kommentare verlassen müssen, die falsch sein können. Selbst wenn die Bezeichnung inhaltlich nicht falsch ist, kann sie je nach Interpretation verwirren. Ich möchte mich beim Debugging lieber auf automatisch generierte Informationen verlassen können.


Wenn ich persönlich eine Installation aufsetze, benenne ich jedes Interface nach dem Schema
nicN_VLAN####_*Bezeichnung*
und zukünftrig wirds dann auch
NIC_VLAN####_in####_*Bezeichnung* geben.

Eine Installation von mir würde seit QinQ dann in etwa so aussehen:

Beispiel 3

Interface                                  Network port

vmx0_WAN                                   vmx0 vmx0_WAN( 00:11:22:33:44:55 )
vmx0_WAN_PPPoE_Telekom           pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
vmx1_untagged_LAN                     vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )
vmx2_vID0100_WiFi_Privat            vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
vmx2_vID0200_WiFi_Gast             vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
vmx2_vID0300_WiFi_Smart           vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
vmx2_vID0400_WiFi_HomeOffice    vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
vmx2_vID0999_in1000_Kunde1_DB qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
vmx2_vID1000_Kunde1                  vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000

Ich finde das ziemlich unübersichtlich. Dem aufmerksamen Leser wird aufgefallen sein, dass hier ein paar Fehler  drin sind. Also sortiere ich die Liste doch mal nach Network port aufsteigend, vielleicht hilft das bei der Lesabarkeit und dem Debugging.

Beispiel 4

Interface                                  Network port

vmx0_WAN_PPPoE_Telekom           pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
vmx2_vID0999_in1000_Kunde1_DB                  qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
vmx2_vID0200_WiFi_Gast             vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
vmx2_vID0300_WiFi_Smart           vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
vmx2_vID0400_WiFi_HomeOffice   vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
vmx2_vID0100_WiFi_Privat            vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
vmx2_vID1000_Kunde1                vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000)
vmx0_WAN                                   vmx0 vmx0_WAN( 00:11:22:33:44:55 )
vmx1_untagged_LAN                     vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )

Ich finde, das hats nicht besser gemacht.

Nicht jeder ist bei der Benennung von Interfaces so gründlich und jeder hat auch ein anderes System wie er Interfaces bezeichnet. Daher gibts die Tabelle 3 jetzt mal ohne mein Schema, nur mit der Bezeichnung. Die Tabelle ist nach Interfaces sortiert.

Interface                                  Network port

Kunde1                                   vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000
Kunde1_DB                             qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
untagged_LAN                         vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )
WAN                                       vmx0 vmx0_WAN( 00:11:22:33:44:55 )
WAN_PPPoE_Telekom               pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
WiFi_Gast                               vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
WiFi_HomeOffice                     vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
WiFi_Privat                             vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
WiFi_Smart                             vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)

Das gleiche zum Spass noch nach Network port sortiert.

Interface                                  Network port

WAN_PPPoE_Telekom               pppoe0 (vmx0 - 01233489534593475#0000@t-online.de)
Kunde1_DB                             qinq01 vmx2_vID999_in1000  ( Parent: vlan01, Tag:1000)
WiFi_Gast                               vlan01  vmx2_vID0200 (Parent: vmx2, Tag:300)
WiFi_Smart                             vlan02 vmx2_vID0400 (Parent: vmx2, Tag:200)
WiFi_HomeOffice                     vlan03 vmx2_vID0300 (Parent: vmx2, Tag:400)
WiFi_Privat                             vlan04 vmx2_vID0100 (Parent: vmx2, Tag:100)
Kunde1                                   vlan05 vmx2_vID1000 (Parent: vmx2, Tag1000
WAN                                       vmx0 vmx0_WAN( 00:11:22:33:44:55 )
untagged_LAN                         vmx1 vmx1_untaggedvmx0_WAN( AA:11:22:33:44:55 )

Ich hab das Beispiel jetzt nur mit 9 Interfaces gemacht. Wir haben in Produktivumgebungen weit mehr Interfaces.

Was ich damit aufzeigen will ist, dass mir das aktuelle Schema als Benutzer aktuell keine Chance lässt, bei einer Installation bei der ich die Interfaces nicht selbst benannt habe so zu sortieren, dass ich mir schnell einen Überblick verschaffen kann. Einfach deshalb, weil es keine Möglichkeit gibt, die Tabelle so zu sortieren, dass ich ein erwartbares Ergebnis habe. Im Verzeichnisdienst sortier ich die Objekte doch auch nicht nach SSID und co. ;-)

Und selbst wenn man ein durchdachtes Schema bei der Description des Interfaces einhält hilft mir das beim Debugging auch nicht schnell weiter, weil die Infos in der Spalte Network port durcheinander sind. Das Auge braucht einfach bis es sich zurecht findet und die richtigen Infos hat.


Daher für die Assignments-Tabelle folgenden konkreten Vorschlag:

Interface                  Network port (Dropdown-Menü)       

*Description*           *NIC*_VLAN####_QinQ#### ( *MAC* )

*Description* kann ohne individuelle Bezeichnung gerne WAN, LAN oder OPT* bleiben bzw. die Description, die man selbst gewählt hat
- *NIC* kann ein phys/virt NIC oder lagg sein
- VLAN#### und QinQ#### sind natürlich nur optional, aber mit dieser Notation ist weiterhin alles enthalten.
- VLAN#### sollte der Q-Tag sein, gerne auch immer mit führenden Nullen, das erleichtert die Lesbarkeit weiter.
- QinQ sollte der AD-Tag sein
- *MAC sollte klar sein. Sollte übrigens auch bei VLAN und QinQ-Interfaces dran stehen.


Anmerkungen dazu und alternativ ein paar Gedankenanstöße falls das konkret vorgeschlagene Schema nicht gefällt:

- "_" find ich als Trennzeichen gut. Das ist besser zu erkennen wie ein ".". Ich würde auch aus historischen Gründen für "_" stimmen. Letztendlich ist aber _, - oder . OK.
- Die Spalte Network-Port oder besser gesagt die Dropdowns dürfen gerne noch ein paar Zeichen länger sein.  FullHD ist heute Standard, in der Tabelle gibts aktuell nur zwei Spalten und es hat genügend Platz.
- Die Info, welches VLAN## oder QinQ## hinter einem Network Port steckt ist in etwa so interessant wie die Info, ob mein dreisigstes Interface tatsächlich OPT28 ist oder weil ich zwischenzeitlich schon welche gelöscht hab doch eher OPT50. Die Info passt besser ins Menü Overview.

- Es wäre auch vorteilhaft, wenn ich einer physical NIC, also dem Device vmx0 eine Description geben könnte. Das fehlt und es wäre vorteilhaft, wenn ich dem Adapter selbst die Info geben könnte, ob es sich um die rechte oder linke Karte in meinem Server handelt, etc.



Oben aufgeführte Argumente gelten in ähnlicher Form auch für das Menü Other Types -> VLAN:

- Aktuell hab ich dort nic#_vlan# -, vlan# - und qinq# -devices. Das ist durcheinander, wenn man es sortiert und dem geschuldet, dass man jetzt Altlasten mit rumschleppt bzw. die neue Bezeichnung drin hat.

- Selbst wenn ich nur noch vlan## und qinq## habe: was bringt mir die Sortierung danach (Stichwort SSID/UUID)? Ich würde auch dort gerne das alte Schema in der Spalte Device sehen. Von mir aus kann ja VLAN## oder QinQ## in Klammern dahinter stehen.

- Was wenn ich wissen will, welche VLANs auf dem Parent vmx1 liegen?
-> Sortiere ich nach Parent, sind die Tags in der nächsten Spalte durcheinander. Man hat also wieder keine Möglichkeit, ein erwartbares Ergebnis zu kommen sondern muss die Tabelle chaotisch durchsuchen.
-> Die Sortierung nach Tags ist da noch einigermaßen nützlich. Es hilft mir aber nicht, meine Frage zu beantworten.




Hoffe, das war ausführlich genug ;-)

95

German - Deutsch / Re: Bug bei der Benennung von neuen VLAN-Interfaces?

« on: April 27, 2022, 06:59:43 pm »

Ich schreibs lieber hier auf deutsch, anstatt mir im englischen Thread einen abzuwürgen. ;-)

@franco: Ich verstehe den Grund wieso sich das geändert hat. Und ich würde deine Aussage, dass in der Oberfläche alles mögliche anzupassen ist und es unter der Haube möglichst einfach gehalten werden muss gerne aufgreifen.

Es wäre wirklich vorteilhaft, wenn in der Oberfläche weiterhin das alte Schema genutzt wird und das neue Schema nur beiläufig erwähnt wird - ähnlich wie das bei OPT-Interfaces ist. Heißt: Es wäre gut, wenn Interfaces mit VLAN-devices weiter im bisherigen Schema vmx0_vlan35 angezeigt werden.

Die ganzen Anleitungen im Internet und (zumindest unsere und wahrscheinlich auch viele andere) Dokumentationen bauen auf dem gewohnten Schema auf. Der Bezug sollte schon allein deshalb gewahrt bleiben, sonst endet das doch nur im Chaos, weil es in Anleitungen und Dokumentationen zu Verwirrung führt.

Bei QinQ-Interfaces sollte das genauso gehandhabt werden. Unter der Haube kann das gerne QinQ## heißen und auf irgend einem VLAN##-Interface aufbauen. In der Oberfläche sollte das aber sprechend sein und der Zusammenhang zwischen NIC, outer Q und inner Q sofort erkennbar sein.

Ich würde für QinQ/AD-Tagging eine Schreibweise bevorzugen, die sich an der Schreibweise von VLAN-Interfaces anlehnt. In der Oberfläche könnte das dann so aussehen: vmx0_vlan35_in450. Wer mit QinQ was anzufangen weiß, der wird gleich erkennen, was Sache ist. Konzequenterweise wäre auch vmx0_vlan35_qinq450 ganz gut.

Aus Erfahrung hab ich übrigens noch nie Probleme gehabt, wenn in der Oberfläche ein physisches oder VLAN-Interface mit mehr als 16 Zeichen benannt wurde, eben weil es im UI keine Rolle spielt. Das sollte bei QinQ dann doch auch möglich sein.

Die Bezeichnung vlan## und qinq## müssen in der Oberfläche dann nur noch beiläufig aufgeführt werden.

96

22.1 Legacy Series / Re: [SOLVED] 22.1.4_1: Weird device nomenclature on 11th vlan subinterface

« on: April 26, 2022, 10:58:22 pm »

First of all, QinQ is a nice feature. Thanks for implementation.

But, in my opionion, naming new vlan devices like vlan01, vlan02 and so one is a really bad idea. 

It should be possible to identify the NIC, the outer Q and the inner Q through a meaningful devicename. With the new scheme vlan##, one simply dont know which NIC and inner/outer Q is assigne to the interface when hes whatching in the Assignement-menu. Imagine how work-intensive it is to verify if interfaces are assigned to the correct vlan devices in case of troubleshooting or reconfigurations. For example, we have a installation with around 30 interfaces...

If the main reason is a limitation of 16 chars, just use shorter strings for QinQ/AD-tagging. But first of all, leave the old convention (vmx#_vlan####) for 802.1q-tagging, because this is the established gold-standard for standard vlan devices, which is described in nearly every sense-documentation out there. You create  massive confusion if you change this for Q-tagging-devices.

For 802.1AD-tagging, please use smarter or a total new convention, because there is no established spelling for this. The reason is simple: QinQ is simply not widely spread.




nicN_QQQQinADAD = vmx0_1111in0022 (15 chars)
nicniN_QQQQiADAD = sfxge0_1111i0022 (16 chars)

or, if you think that one will install more than 10 NICs in one server:

nicniNN_QQQQADAD = sfgge10_11110022 (16chars)

OK, i hope, that there are no NICs with 6 chars + N, but i think there will a solution.... Just be creative for QinQ-device-names, but please, leave the device-names meaningful and Q-tagged devices in the old scheme. Thanks.

97

German - Deutsch / Re: Bug bei der Benennung von neuen VLAN-Interfaces?

« on: April 26, 2022, 09:53:50 pm »

Hilf mir bitte auf die Sprünge. Welche Release-Note ist das? Und wo ist die Diskussion dazu bzw. was waren die Hintergründe zu diesem Change? Würde da gerne meine Meinung zu kundtun. Ich kann da nicht wirklich Vorteile erkennen...

98

German - Deutsch / Bug bei der Benennung von neuen VLAN-Interfaces?

« on: April 26, 2022, 09:33:06 pm »

Moin,

wir haben eine OPNsene mit aktueller Version 22.1.6 in einer VMware VM mit zwei vNICs laufen (vmx0 und vmx1).

Wenn wir in der Vergangenheit VLAN-Devices angelegt haben, haben diese immer die Device-Bezeichnung z.B. vmx0_vlan345 erhalten. Wir haben so schon etwa etwa 30-40 Interfaces auf vmx0 angelegt, die alle nach dem Schema benannt wurden.

Wenn ich jetzt ein neues VLAN-Interface anlegen möchte, wird das nicht mehr nach dem alten Schema vmx#_vlan#### benannt, sondern die heißen jetzt alle vlan01, vlan02 etc... und werden fortlaufen nummeriert. Wir können diese Bezeichnung aber nicht ändern.

Wenn ich also das VLAN-Device zu einem Interface assignen will, muss ich als Device vlan01 etc. in der Dropdown-Liste auswählen. Nach dem hinzufügen sehe ich in der Assignment-Liste nur noch diese neue Bezeichnung und kann nicht mehr erkennen, welchem Interface welches VLAN-Device untergeordnet ist.

Die alten Devices die mit vmx#_vlan#### angelegt wurden bleiben aber bestehen und funktionieren weiterhin.

Ist das ein Bug? Oder wie nennt man das VLAN-Interface nach seinen Vorstellungen um?

99

Virtual private networks / Re: wireguard dynamic WAN IP

« on: April 04, 2022, 12:54:57 pm »

Thank you. Will test this script.

I also opened a feature request here: https://github.com/opnsense/plugins/issues/2927

If you are interested in this, please support it on github.

100

Virtual private networks / Re: wireguard dynamic WAN IP

« on: April 03, 2022, 08:53:42 pm »

I am running wg site 2 site with opnsense at links with dynamic IPs. So the IPs change mininimum every month while updating opnsense.

ONCE, when the tunnel is started. Never afterwards, even if the DynDNS get's updated and therefore the tunnel fails...

Is this still the case?

Is there a workaround/script/something like that to solve this problem?

101

German - Deutsch / Welcher Eintrag genau in "Allowed IPs" damit OSPF über Wireguard funktioniert?

« on: March 06, 2022, 07:52:51 pm »

Moin,

ich wollte vom statischen Routing zwischen zwei Sites auf OSPF mit FRR über Wireguard umsteigen. Das hat mich einiges an Zeit gekostet, weil sich die OSPF-Neighbours ewig nicht gefunden haben.

Ich hab im Interface von OSPF im Network Type von "none" über "Broadcast multi-access network"  und "Point to Point network" etc. alles ausbrobiert, aber nichts hat geholfen, obwohl ich von beiden Seiten von Clients aus die Tunnelendoints der Remotesite pingen konnte und statisches Routing auch funktioniert hat.

Die Neighbours haben sich erst gefunden, als ich in Wireguard bei Allowed IPs alle Einträge rausgeworfen hab und nur noch die  0.0.0.0/0 eingetragen habe (der Network Type von OFSP ist  dabei nun übrigens auf Broadcast eingestellt).

Wieso? Was schickt OSPF da über den Tunnel, bzw. wieso sehen sich die Neighbours erst, wenn über den Wireguard-Tunnel alles ( 0.0.0.0/0 ) drüber darf?  Und wieso machts keinen Unterschied, ob man none, Broadcast oder Point to Point als Network Type nutzt?  Welches Netz müsste ich da exakt eintragen, damit OSPF sauber durch geht?

Ich hätte erwartet, dass sich eigentlich nur die zwei TEPs im Tunnel erreichen müssen und OSPF als Firewallregel erlaubt werden muss, damit sich die Neighbors finden. Dem scheint wohl nicht so zu sein.

Ja, ich weiß, Firewallregeln sind jetzt das Mittel der Wahl. Aber geht das auch etwas granularer, so dass man auch im Tunnelsetup schon einschränken kann, was da grundsätzlich alles an Netzen drüber darf? Ich hätte nämlich gerne, dass auch bei Nutzung von OSPF bei Allowed IPs im Wireguard Tunnel nicht 0.0.0.0/0 steht, sondern nur das Netz in dem sich die zwei Tunnelendpunkte befinden, sowie z.B. der Netzbereich der sich auf der anderen Seite befinden (z.B. ein /16 Bereich oder so).


Vielen Dank für die Erleuchtung.

102

German - Deutsch / Re: QinQ / 802.1ad Support ?

« on: March 02, 2022, 09:55:09 pm »

Was für ein Zufall!

Danke für das Feedback und die Erklärung zur Historie. Ja, sieht nach weniger Code aus.

Falls jemand zu den restlichen Fragen noch Informationen hat, wäre ich dankbar.

Edit: Und danke auch für die unermüdliche Arbeit an OPNsense. :-)

103

German - Deutsch / QinQ / 802.1ad Support ?

« on: March 02, 2022, 08:45:53 pm »

Moin,

die pfsense scheint QinQ zu beherrschen: https://docs.netgate.com/pfsense/en/latest/interfaces/qinq.html

Die OPNsense scheinbar leider nicht. Zumindest kann ich, wenn ich ein neues VLAN-Interface anlegen will, kein VLAN-Interface als Parent-Interface auswählen.

Ist das eine Frage der OS-Basis oder eine Frage des OPNsense codes?

Und, falls das jemand weiß:

Einige Switche können QinQ nativ. Das heißt, sie supporten 802.1ad und können den äußeren VLAN-Tag entfernen und dann den inneren VLAN-Tag nutzen um den Frame tagged oder untagged auf einen Port zu legen.

Wenn ich mir so den Aufbau von 802.1ad bei Wikipedia angucke, dann würde ich vermuten, dass möglicherweise der ein oder andere "dumme unmanaged Switch" in der Lage sein sollte, QinQ weiterzuleiten, schließlich brauchen diese Switche nur Ziel und Quell-Mac und kümmern sich nicht drum, was zwischen Source-Mac und CRC steht. Oder prüfen solche Switche den Ethertype ? Hat da jemand Erfahrung? Oder Erfahrung damit, was einfach getaggte 802.1Q-Frames über "dumme" Switche schicken angeht? Sollte ja dann übertragbar sein auf QinQ-Frames. Dass die MTU dann beim Absender ggf. um entsprechende Bytes kleiner sein muss, ist klar.

Wie siehts miit managed switches aus, die kein QinQ können? Können die es durchreichen? Vermute mal nicht, weil die sich wahrscheinlich für den Ethertype interessieren, aber sicher bin ich mir da nicht.  Hat da jemand Erfahrung?

104

German - Deutsch / Re: Verständnisfrage zum Bridging

« on: March 02, 2022, 08:04:01 pm »

Danke für die Info.

105

German - Deutsch / Verständnisfrage zum Bridging

« on: March 02, 2022, 10:50:11 am »

Hallo zusammen,

nur um mich zu vergewissern:

Bridging ist dazu da, um zwei Layer2-Netze zu einer Broadcast-Domain zu machen, richtig?

Anders ausgedrückt: Bridging macht die Opnsense auf den beteiligten Interfaces zu einem Switch, richtig?

Welche Limitationen hat so eine Bridge? Klappen Broardcasts ohne Einschränkungen? Können DHCP-Server auf der einen Seite von DHCP-Clients auf der anderen Seite erreicht werden?

Geht da VLAN, IGMPV3 etc. durch?

Danke für den Input.

Viele Grüße