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.
Mir ist bei der Checksumme aufgefallen, dass es offenbar immer die Gleiche ist:
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... .
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.
[bad udp cksum 0x8e46 -> ...]
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.
Mir ist aufgefallen, dass an meinem WAN Interface (igb3) immer noch diverse Beschleunigungsoptionen zu sehen sind, wenn ich mir mit 'ifconfig' alles anzeigen lasse.
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.
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...
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?
Bei der GO-Wireguard Implementierung ist das Verhalten genauso. D.h. Checksummen-Fehler und kein Handshake.
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.
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.
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.
Stimmt. Ich glaube das Neustarten des Dienstes habe ich tatsächlich bisher vergessen :) Danke für den Tipp. Probiere ich aus.
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...
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.
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.
Mein nächster Schritt wäre vermutlich Wireguard komplett zu entfernen und neu einzurichten.
Ich hatte die Konfiguration ja von meinem alten Router übernommen der hinter der Fritzbox hing.
Ich schrecke noch etwas davor zurück, weil ich die Regeln für das Interface nicht einzeln sichern kann.
Evtl. schaue ich mal ob ich die Regeln in der Backup-Datei finde. Dann könnte ich sie dort auch wieder eintragen.
Die Weiterleitung an das WG-Interface habe ich absichtlich noch nicht ausprobiert, weil Wireguard für mich aktuell kein kritischer Dienst ist und ich erstmal versuche das so hinzubekommen wie es meiner Meinung nach laufen sollte.
Hallo MenschAergereDichNicht!
Kurze Frage hast Du es noch hinbekommen? Ich habe scheinbar das gleiche oder ein ähnliches Problem.
Ich habe ein Wireguard Setup für die kleine Firma von einem Bekannten eingerichtet, ich habe es genauso gemacht wie hier in der Anleitung: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten
Allerdings erfuhr ich dann vor Ort, dass eine Telekom DSL Leitung mit einem DrayTek Vigor 130 zum Einsatz kommt. Hier kann man sich nur per PPPoE einwählen, wenn man für das WAN Interface ein VLAN mit dem Tag 7 anlegt. Das war mir vorher so nicht bewusst und hat mir mein remote Administrations-Konzept etwas zerrissen. Ich bekomme es auf absolut nicht hin eine Wiregurad Verbindung zur OPNsense aufzubauen. Erst dachte ich es liegt an meinen Firewall-Regeln (die müssten ja analog zur Anleitung sein nur eben für das angelegte VLAN statt dem WAN Interfacce) aber daran scheint es nicht zu liegen. Mit den MTUs hatte ich jetzt wegen deinem Posting auch noch mal probiert, derzeit habe ich auf dem pppoe-vlan 1492 und für WG 1432. Ebenso mit dem Hardware CRC offloading, das ich auch deaktiviert habe.
Aber wirkt alles nicht und ich sehe das Problem jetzt nicht so ganz.
LG
Hovy
Mittlerweile habe ich noch ein WG Interface für das von dem wireguard-go plugin angelegem Interface angelegt und hier einen Zugriff zu allen Netzen erlaubt (inkl. sich selbst) aber ich kann gar nicht erst eine Verbindung aufbauen.
@Hover, bitte mehr informationen
- bitte mal einen grafischen netzwerkplan
- bitte mal screenshots von deiner wireguard konfiguration (server/client)
- scrennshost deiner firewall regeln
- der telekom anschluß hat wirklich eine ipv4 und kein CGN (feste ip oder dyndns)?
hast du es mal alternativ mit openvpn versucht?
Klar, gerne.
Ich bin im wesentlichen diesem Tutorial gefolgt: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten#
Ich habe bei mir zuhause selbst ein ähnliches Setup aber bei einem anderen Provider. In dem Fall um den es hier geht wird ein DrayTek Vigor 130 Modem zur Einwahl bei der Deutschen Telekom verwendet. Dafür musste ich leider ein VLAN für das WAN Interface anlegen das die VLAN ID 7 hat. Dadurch sind die Regel für WAN hier auf das VLAN Interface "DrayTekTKom" angewendet worden.
Netzplan
https://ibb.co/vh3LT6j
VLAN Interface für Telekom Einwahl
https://ibb.co/X32C1V8
WG Local Config
https://ibb.co/TRDbSnZ
WG Endpoint Config
https://ibb.co/6RDbqBY
Firewallregeln VLAN
https://ibb.co/cyLgBGs
Firewall Regeln WG Interface [mehr aus Verzweifelung weil ich keine Lösung finde]
https://ibb.co/NFBMqrx
Firewall Regeln WG (Group) [mehr aus Verzweifelung weil ich keine Lösung finde]
https://ibb.co/t3bSYk5
Firewall Regeln WAN [Als Test als ich keine Lösung fand]
https://ibb.co/98KGK6J
Das seltsame ist das ich noch nicht mal einen Handshake laut Wiregurad log kriege aber z.B. die ICMP Regel im WAN VLAN einwandfrei funktioniert wenn ich sie aktiviere. Ich wundere mich etwas da ich ein ziemlich ähnliches Setup hier zuhause habe und auch schon anderorts aufgesetzt habe. Aber noch nie auf einer Telekom Leitung, diese hat sogar eine statische IP und einen TLD subdomain der auf diese zeigt.
Auch die Client configs sind an sich jetzt nicht besonders.
[Interface]
Address = 10.1.0.4/32
PrivateKey = [cut]
[Peer]
PublicKey = [cut]
AllowedIPs = 10.1.0.0/24, 192.168.59.0/24, 192.168.9.0/24
Endpoint = gw.domain.de:51820
In dem Thread hier ging es ja darum das es scheinbar ein Problem mit den CRC Checks oder den MTUs gibt bei Wireguard und einem ähnlichen Setup. Frage ist halt ob das hier ein Bug ist oder ich Tomaten auf den Augen habe. Initial hatte ich es intuitiv genau so wie in dem oben geschriebenen Tutorial gemacht. Nur eben mit dem VLAN Interface von für das WAN. Kann es sein das es ein generelles Problem mit T-Kom Setup mit Vigor 130 Modem und Wireguard gibt?
Hovy
Edit: Mit OpenVPN habe ich es noch nicht probiert ich war jetzt erstmal irritiert warum es mit Wiregurad nicht geklappt hat.
Quote from: Hover on December 19, 2022, 03:03:48 AM
Kann es sein das es ein generelles Problem mit T-Kom Setup mit Vigor 130 Modem und Wireguard gibt?
Nein. Habe ich an mehreren Standorten am Laufen. Allerdings lasse ich immer den Vigor das VLAN Tag setzen.
Sonst kann ich an deiner Konfiguration jetzt auf den ersten Blick nichts Falsches erkennen.
QuoteAllerdings lasse ich immer den Vigor das VLAN Tag setzen.
Ahh, ich denke genau daran wird es liegen, dadurch ändert sich ja einiges an den Firewall-Regeln und soweit ich weiß ist das Wireguard-Go Plugin nur Userspace, das führt natürlich zu weiteren Einschränkungen.
Ich bin seit über 20 Jahren nicht mehr bei der Telekom und die Modems die ich bisher hatte, hatten alle immer direkt PPPoE unterstützt.
Könntest du mir vllt einen Screenshot machen wie du es konfiguriert hast in deinem Vigor 130? Nur um sicher zu gehen? Ich kann da leider gerade nur remote auf die Infrastruktur zugreifen und müsste dann vllt jemanden anweisen das so einzustellen.
LG
Hovy
An den Firewall-Regeln ändert sich dadurch eigentlich nichts, nur an der Interface-Konfiguration. Sonst ist irgendetwas falsch.
Mein WAN: ein PPPoE auf einem phys. Interface
Dein WAN: ein PPPoE auf einem VLAN auf einem phys. Interface
Firewall-Regeln beziehen sich immer auf das abstrahierte WAN.
Ich schick den Screenshot, wenn ich im Büro bin. Zugriff auf den Vigor gibt's nur direkt vor Ort.
Sodele ...
Hallo pmhausen,
danke Dir, die Oberfläche von dem Vigor 130 sieht etwas anders aus aber vermute mal die Einstellungen werden ähnlich sein.
Frohe Weihnachten und einen guten Rutsch!
Hovy