Wireguard über PPPoE mit Vlan

[MenschAergereDichNicht]

Hallo,

ich bin kürzlich von DSL auf eine Glasfaserverbindung umgestiegen. Mein Provider verwendet PPPoE mit einem VLAN für die Anbindung.
Da ich für die neue Verbindung auf die Fritzbox verzichten möchte, habe ich meinen OpnSense-Router direkt mit dem Medienkonverter verbunden (vorher bei der DSL-Verbindung stand er hinter der Fritzbox und war per DHCP angebunden). Das funktioniert auch sehr gut.

Allerdings scheint mein Wireguard-Setup nach dem Umzug nicht mehr zu funktionieren. D.h. der Handshake funktioniert nicht mehr.

Wenn ich am pppoe0-Interface ein Tcpdump mache, sehe ich die eingehenden Anfragen. Es werden offenbar auch UDP (Antwort?)-Pakete vom Router an den Client geschickt. Die scheinen allerdings auf der Strecke zu bleiben, weil am Handy nichts ankommt.
Wenn ich bei Tcpdump den Loglevel hochdrehe (-v) sehe ich, dass bei den verschickten UDP-Paketen ein Checksummen-Fehler vorliegt. Könnte das die Ursache sein?
Ich habe daraufhin bereits sämtliches Hardware Offloading deaktiviert. Das hat leider nicht geholfen (nach wie vor Checksummen Fehler).

Da ich zusätzlich zum neuen Anschluss die Konfiguration auf einen anderen (baugleichen) Router übertragen habe, bin ich mir nicht sicher, ob es an der PPPoE-Anbindung liegt oder ein generelles Problem ist, das vorher wegen historischen Anpassungen auf dem alten Router nicht aufgetaucht ist.

[MenschAergereDichNicht]

Mir ist bei der Checksumme aufgefallen, dass es offenbar immer die Gleiche ist:

Code: [Select]

Paket 1: [bad udp cksum 0x8dc8 -> 0x168a!]
Paket 2: [bad udp cksum 0x8dc8 -> 0x520e!]

Wenn ich das richtig deute, ist das immer die falsche Checksumme 0x8dc8 und die richtige steht dann dahinter.
Etwas seltsam, dass da immer die gleiche Checksumme abgelegt wird... .

[MenschAergereDichNicht]

Ich habe jetzt das ppoe0- und das Vlan-Interface, nach dem Deaktivieren des Hardware Offloads, neu angelegt. Leider ist der Checksum-Fehler immer noch vorhanden. Allerdings mit einer anderen fehlerhaften Summe bei allen Paketen.

Code: [Select]

[bad udp cksum 0x8e46 -> ...]


[MenschAergereDichNicht]

Zusätzlicher Datenpunkt:

Ich verwende das Wireguard Kernel-Modul und IPv6.

In dem Zusammenhang habe ich einen Austausch in der Freebsd Mailingliste vom Februar diesen Jahres gefunden (https://lists.freebsd.org/pipermail/freebsd-net/2021-February/057463.html).

Da gab es auch Checksummen-Fehler.

Allerdings hat das Setup so ja vorher bei dem DHCP-Wan funktioniert (auf dem anderen, baugleichen Router)... .

Vermutlich sollte ich mal ausprobieren, ob es mit der go-Implementierung funktioniert.

[MenschAergereDichNicht]

Mir ist aufgefallen, dass an meinem WAN Interface (igb3) immer noch diverse Beschleunigungsoptionen zu sehen sind, wenn ich mir mit 'ifconfig' alles anzeigen lasse.

Code: [Select]

igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether XX:XX:XX:XX:XX:XX
inet6 YY::YYY:YYYY:YYYY:YYYY%igb3 prefixlen 64 scopeid 0x4
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Da das bei den übrigen Schnittstellen nicht so ist, gehe ich davon aus, dass es nur angezeigt wird, wenn es aktiv ist.
Das ist etwas seltsam, weil ich in den globalen Einstellungen alle Hardware-Features deaktiviert habe.

[MenschAergereDichNicht]

Ich habe auf meinem alten Router (APU 4D4; 4 Netzwerkschnittstellen) OpnSense frisch neu installiert ohne Konfigurationsanpassungen. Nach der Installation ein Update auf die aktuelle Version gemacht und dann in die Interface-Einstellungen des Web-Interfaces geschaut. Dort ist die Hardwarebeschleunigung deaktiviert.

Wenn ich in der Shell mit ifconfig nachschaue, sind bei igb0 und igb1 die Optionen *nicht* vorhanden, bei igb2 und igb3 aber sehr wohl.

Ich weiß zwar nicht wirklich, ob das etwas mit meinem Problem zu tun hat, allerdings fühlt es sich etwas komisch an.

Evtl. liegt es daran, dass ich zu dem Zeitpunkt nur igb0 und igb1 in Betrieb hatte (als LAN und WAN) und igb2 und igb3 noch nicht ans Netz angeschlossen waren. D.h. evtl. wird das erst bei der ersten Aktivierung gesetzt?

Evtl. ist das auch das Problem bei meinem Produktiv-Router? Ich habe ja dort das igb3-Interface nie "direkt" verwendet, sondern nur indirekt über das VLAN- und PPPoE-Interface...

[MenschAergereDichNicht]

Evtl. hat mein Wireguard-Problem auch mit dem unter https://forum.opnsense.org/index.php?topic=16070.0 angesprochenen Fall zu tun.

Todo-Liste:

1) Versuchen die Hardwarebeschleunigung vom igb3-Interface zu entfernen
2) GO-Implementierung ausprobieren
3) Portweiterleitung von WAN zum wg-Interface?

[MenschAergereDichNicht]

Bei der GO-Wireguard Implementierung ist das Verhalten genauso. D.h. Checksummen-Fehler und kein Handshake.

[MenschAergereDichNicht]

Bezüglich der Hardwarebeschleunigung am igb3-Interface.

Ich kann sie deaktivieren wenn ich folgendermaßen vorgehe:

- WAN-Interface von PPpoE auf DHCP stellen
- Unter Interface Assignments das WAN-Interface umstellen auf igb3

Dann werden für igb3 offenbar die globalen Einstellungen angezogen. Wenn ich danach alles wieder mit PPPoE konfiguriere, bleibt die Hardwarebeschleunigung weiterhin deaktiviert.

Das Problem in dem Fall ist nur, dass das nach einem Router Neustart alles wieder aktiv ist. D.h. es sieht mir danach aus, dass direkt nach dem Booten erstmal bei allen Interfaces die Hardwarebeschleunigung aktiv ist.
Dann wird im Anschluss überall dort wo ein Link besteht, entsprechend den globalen Einstellungen, ggf. ein Feature deaktiviert.
Das scheint in Zusammenhang mit dem VLAN- und PPPoE-Interface nicht ganz aufzugehen.
(Bugreport an das OpnSense-Projekt => https://github.com/opnsense/core/issues/5391)

Immerhin konnte ich ausprobieren, ob durch das Deaktivieren der Hardwarebeschleunigung irgend etwas besser wird. Das ist nicht der Fall. Es gibt weiterhin den Checksummen-Fehler und das dazugehörende UDP Antwort-Paket des Wireguard-Handshakes erreicht weiterhin nicht sein Ziel.

Nachtrag: Da ich wegen dem oben beschriebenen Problem keinen Reboot nach dem Deaktivieren der Hardwarebeschleunigung machen konnte, bin ich mir nicht sicher, ob die Aussage richtig ist. Es könnte ja sein, dass es eine Anpassung ist, die erst durch einen Neustart korrekt im gesamten Stack verteilt wird.
 

[MenschAergereDichNicht]

Der UDP Checksummen-Fehler scheint kein generelles UDP Problem zu sein, weil er bei anderen Programmen nicht auftritt.
D.h. Wireguard scheint da irgend etwas Spezielles zu machen.

Ich habe dazu noch das hier gefunden:
https://www.mail-archive.com/wireguard@lists.zx2c4.com/msg04429.html

Dort ist ja eine Lösung die Hardwarebeschleunigung zu deaktivieren... In Zusammenhang mit dem von mir berichteten Bug ist das natürlich nicht so toll.

[Patrick M. Hausen]

Mach doch auf der Shell mal systematisch alles aus und starte dann den WireGuard Service über das UI neu.

ifconfig <interface> -vlanhwtag
ifconfig <interface> -vlanhwcsum

und so weiter und so fort bis alles aus ist.

[MenschAergereDichNicht]

Stimmt. Ich glaube das Neustarten des Dienstes habe ich tatsächlich bisher vergessen  Danke für den Tipp. Probiere ich aus.

[MenschAergereDichNicht]

Mit dem In-Kernel Wireguard hat das leider auch nicht geholfen. Ich wollte es dann nochmal mit der GO-Variante testen. Dann habe ich allerdings Probleme bei der Einwahl bekommen.
Ich glaube ich habe mich für den Provider zu oft eingewählt oder so etwas und bin in einen temporären Bann geraten (das Point-to-Point Log sah so ähnlich aus wie zu der Zeit als ich noch nicht freigeschaltet war). Jetzt läuft es wieder. Allerdings hat mich für heute mein Mut verlassen weitere Dinge auszuprobieren, weil ich morgen für das Homeoffice auf mein WAN-Interface angewiesen bin...

[MenschAergereDichNicht]

Franco hat mir an dem Github-Issue den Hinweis gegeben für das Basis WAN-Interface (igb3) eine eigene Zuweisung anzulegen. Tatsächlich werden jetzt die Offload-Einstellungen auch nach einem Neustart berücksichtigt.

Leider funktioniert Wireguard immer noch nicht und ich sehe immer noch UDP Pakete mit einem Checksummen-Fehler. Offenbar hat das aber nichts mit der Hardware-Beschleunigung zu tun.

[MenschAergereDichNicht]

Nach weiterem Surfen habe ich noch einen Hinweis darauf gefunden, dass es bei einer PPPoE-Verbindung evtl. an der anderen MTU liegen könnte.

Referenz bezüglich Wireguard Paketgrößen: https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html

Wenn ich mir die MTU des wg0-Interfaces anschaue, sehe ich, dass sie auf 1420 (1500 - 80 für Wireguard) gesetzt wurde. Das ist im PPPoE-Fall nicht richtig. Da fehlen die 8 Byte für den PPPoE-Header. (Bugreport => https://github.com/opnsense/core/issues/5393)

Daraufhin habe ich die Tunnel-MTU zuerst nur beim Wireguard-Server auf 1412 (1500 - 8 für PPPoE - 80 für Wireguard) gesetzt und dann auch beim Client. Hat leider ebenfalls nicht geholfen. Diesmal habe ich auch an den Neustart des Dienstes gedacht (aktuell verwende ich die GO-Implementierung).

Vermutlich würde die MTU dann ein Problem werden, wenn der Handshake funktionieren würde. D.h. wenn der Traffic durch den Tunnel geleitet wird.