Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Ergo hat keine der Boxen eine von extern erreichbare IPv4. Der Tunnel wird über IPv6 aufgebaut bzw. so sollte es sein. Die MTU wäre der nächste Ansatz. Deshalb mal nicht myfritz verwenden, sondern einen Provider, bei dem man explizit nur den AAAA-Record für IPv6 setzen kann, dann müßte es mit der MTU wieder passen. Ich verwende dynv6.com
Wenn auf beiden Seiten IPv4 mit nicht öffentlichen IPs im Spiel ist (10.* bzw. 100.*) wird das über IPv4 schon mal nix. Reines IPv6 wäre noch ein Ansatz.
Seit kurzem kann man auf Nur IPv6 verwenden umstellen, ich habe das zum ausschließen schon vor paar Tagen probiert. Dann hat die Fritzbox nur noch eine IPV6 Verbindungen.
Ich habe ganz vergessen ich hatte ja noch ein Problem und zwar wenn ich auf meinem Windows PC eine Wireguard Verbindung zur FritzBox 7590 im DG aufbaue geht die Verbindung auch nicht da kann ich dann auch keine Internet Seiten mehr aufrufen aus dem Netz von NetAachen. Bei gleichem Aufbau nur wenn ich dann über das Netz von O2 (Handy Hotspot) verbinde dann geht es plötzlich. Deswegen geht auch die Verbindung auch immer vom Handy aus. Ich bin langsam echt verwirrt. Ich probiere morgen nochmal genau aus was nicht geht. Ahja habe ipv6 direkt genommen ohne DynDns von myfritz.net.
In den Supportdaten der FRITZ!Boxen sollte stehen, welche WAN-seitigen Protokolle verwendet werden. Auch bei IPv6 als Transportprotokoll sind - wenn da noch PPPoE dazu kommt - die 1420 Bytes der Standard-MTU zuviel: https://lists.zx2c4.com/pipermail/wireguard/2017-December/002201.html, weil die IPv6-Header größer sind als die IPv4-Header (40 vs. 20 Bytes).
Hm, da verstehe ich die von Dir verlinkte Quelle (s.u.) anders. Habe ich einen Denkfehler?
The overhead of WireGuard breaks down as follows:
- 20-byte IPv4 header or 40 byte IPv6 header
- 8-byte UDP header
- 4-byte type
- 4-byte key index
- 8-byte nonce
- N-byte encrypted data
- 16-byte authentication tag
So, if you assume 1500 byte ethernet frames, the worst case (IPv6)
winds up being 1500-(40+8+4+4+8+16), leaving N=1420 bytes. However, if
you know ahead of time that you're going to be using IPv4 exclusively,
then you could get away with N=1440 bytes.
Das kann man - bei den wenigen Fakten Deinerseits - nicht einschätzen.
Den "Rechenweg" für die 1420 Bytes, die WG als Standard verwendet, hast Du ja selbst aus der Mailing-Liste zitiert. Wenn da jetzt noch PPPoE als Transportkapselung "außen herum" dazu kommt (wie ich es als "Annahme" in #146 geschrieben habe), gehen dafür noch einmal 8 Bytes von der verfügbaren Paketgröße ab: https://en.wikipedia.org/wiki/Point-to-Point_Protocol_over_Ethernet#Overhead_on_Ethernet (ff.)
Wie kann ich den MTU Wert erhöhen liegt an NetAachen Netz im Handy Netz ist der MTU wert größer und Wireguard geht dann. Die Einstellungen in der Fritzbox im Bild werden automatisch so vom Provider bezogen.
Wieso geht dann eine Wireguardverbindung zu eine FritzBox nicht und zu einem Raspbery ohne Problem?.
Code:
C:\WINDOWS\system32>ping -f -l 1424 www.google.de
Ping wird ausgeführt für www.google.de [142.250.186.131] mit 1424 Bytes Daten:
Antwort von 142.250.186.131: Bytes=68 (gesendet 1424) Zeit=18ms TTL=116
Ping-Statistik für 142.250.186.131:
Pakete: Gesendet = 1, Empfangen = 1, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 18ms, Maximum = 18ms, Mittelwert = 18ms
STRG-C
^C
C:\WINDOWS\system32>ping -f -l 1425 www.google.de
Ping wird ausgeführt für www.google.de [142.250.186.131] mit 1425 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Es geht nicht darum, einen MTU-Wert zu erhöhen ... der wird durch die maximale Größe der auf dem Transportweg zu übertragenden Daten (die physikalische Größe, die max. möglich ist) abzüglich des Overheads durch ALLE zur Kapselung von (Nutz-)Daten verwendeten Protokolle VORGEGEBEN.
Es geht also eher darum, die MTU-Size (beim Zerlegen der zu sendenden Daten durch den WG-Treiber auf der Sender-Seite) so zu VERRINGERN, daß die in einem Paket versendeten (Nutz-)Daten auf allen Zwischenstationen des Wegs zum Empfänger (das geht beim lokalen "Verpacken" los und endet erst wieder beim "Entpacken" "Auspacken" auf der Gegenseite) KOMPLETT übertragen werden können, damit auf der Empfängerseite auch immer komplette (WireGuard-)Pakete ankommen, aus denen der WG-Treiber dann - nach Authentizitätsprüfung, daß da niemand "an den Daten herumgefummelt" hat (tamper with sth.) - die zu übertragenden Daten wieder rekonstruieren kann.
Ich habe auch keine Ahnung, wie sich AVM das vorstellt bei der finalen Version ... üblicherweise gibt es für die Feststellung des max. möglichen Wertes (das nennt sich dann "Path MTU Discovery") einen Standard - nur ist der darauf angewiesen, daß auf allen Zwischenstationen auch die üblichen Signalisierungen funktionieren, mit denen dem Absender dann mitgeteilt werden kann, an welchem "hop" auf dem Weg eines Pakets ein Problem aufgetreten ist (und welches das war). Das funktioniert dann bei VPN-Verbindungen (davon ist ja auch nicht nur WireGuard betroffen) gerne mal nicht und deshalb gibt es bei solchen Lösungen üblicherweise immer eine Möglichkeit, einen passenden Wert manuell einzustellen.
Bei der IPv6-Konfiguration (für das WAN-Interface bzw. dev dsl) kann man im FRITZ!OS ja einen abweichenden MTU-Wert festlegen, wobei die von AVM als Standard vorgeschlagenen 1280 Bytes eigentlich dazu führen sollten, daß man bei (fast) allen Unwägbarkeiten des IPv6-Protokolls (z.B. ist dort die Größe der (IPv6-)Header nicht "fix" festgelegt und kann variieren) zurecht kommen kann.
Ob und wie genau sich eine dort vorgenommene Änderung (die ja bei AVM per se erst mal nur im kdsldmod Auswirkungen hat, wie man sich (bei Shell-Zugriff) mit showdsldstat ansehen kann ... ansonsten findet man das auch in den Supportdaten) jetzt auch automatisch (nach zusätzlicher "Berechnung") auf das konfigurierte WireGuard-Interface auswirkt (auch das sollte sich als wgX in den Supportdaten finden lassen), weiß ich auch nicht (bzw. habe ich noch nie versucht zu ergründen, solange AVM WG noch nicht "offiziell" freigegeben hat) - aber vielleicht ist auch das noch einen Versuch wert und wenn man die IPv6-MTU mit dem vorgegebenen Wert "überschreibt" (dazu muß man nur die Checkbox aktivieren, dann bleibt es bei den 1280 Bytes), dann KÖNNTE es auch sein, daß die MTU auch für WG (und natürlich ebenso für ALLEN anderen Traffic, daher ist das schon mit einem (eher geringen) Verlust an Transfer-Kapazität verbunden) entsprechend verringert wird.
Bei aktivierter WG-Verbindung sollte man auch dazu etwas in den Supportdaten finden können - vorausgesetzt AVM gibt dort auch immer noch die Übersicht der Interfaces (das Ergebnis von ip addr show) aus (was ich jetzt nicht recherchieren oder testen will/werde).
Sollte es dann mit reduzierter MTU-Size doch irgendwann mal (alles) funktionieren, kann man sich - wenn man nicht generell mit der 10% niedrigeren Paketgröße leben kann/will, wobei der Effekt von den meisten stark überschätzt wird - auch wieder an größere Werte "herantasten", bis man den max. möglichen Wert gefunden hat (das hängt eben immer davon ab, was ZWISCHEN den beiden Anschlüssen alles passiert und das KANN sogar wechseln - z.B. beim Mobilfunk-Backup für eine unterbrochene DSL-Verbindung).
Nur eine ergänzende Information zu Peters letzten Beitrag (mit den wie immer guten Hinweisen):
In einer vollständigen WireGuard-Installation unter OpenWrt ist es in den Einstellungen für die Netzwerkschnittstellen (bei mir WG0 bis WG7) unter "Erweiterte Einstellungen" möglich, den MTU-Wert zu ändern. Vorgabe ist 1420.
Ohne triftigen Grund haben die Entwickler diese Einstellmöglichkeit sicherlich nicht eingebaut. Ich habe mich auch ganz langsam an den Wert herangetastet, bei dem es keine Verluste gibt.
Meine Test-Wireguard-Fritzbox verbindet sich über einen LTE-Stick und der Zugriff über die Wireguard-Verbindung funktioniert in beiden Richtungen. Eine Einstellung zur MTU habe ich in der Fritzbox nicht vorgenommen, die Gegenstelle verwendet wie alle meine Wireguard-Geräte 1300.
PS: mit diesem Stick gibts nur eine IPv4, und die ist nicht öffentlich. Aber die Gegenstelle hat ja (noch) eine öffentliche IPv4, das reicht zum Testen.
Ich habe jetzt eine Verbindung aufbauen können vom PC (Windows,Netaachen) zur FritzBox im DG Netz dafür habe ich in der condig den MTU Wert kleiner gesetzt. Leider Funktioniert das nicht bei einer Lan to Lan Verbindung da wird wahrscheinlich kein MTU wert verändert. Ist es möglich das NetAachen meinen MTU wert höcher setzt oder ist das ein Normaler bereich bei DS Lite? Dann wäre der Fehler bei AVM zu melden damit diese da noch was ändern können.
Ich habe unter Zugangsdaten IPV6 MTU manuell einstellen den kleinst möglichen Wert von 1280 probiert aber keine Besserung. Ich warte mal auf ein neuere Labor version.
AVM hat es in dieser Version tatsächlich erneut geschafft, dank grandios logischer Assistenten, die Wireguard Verbindung zwischen Boxen, auf denen bereits Tunnel bestehen, unbrauchbar zu machen. Ein Import von config Dateien führt immer zu Einzelgeräteverbindungen und nicht zu Netzverbindungen.
Warum ist es nicht möglich, den Dialog so zu gestalten, wie er bei IPSec war?
