WireGuard verbindet - Aber kein http möglich

Elsi29

Aktives Mitglied
Mitglied seit
24 Dez 2008
Beiträge
2,866
Punkte für Reaktionen
13
Punkte
38
Hallo,

folgende Konfig: FB 7590 mit aktueller Labor 7.39-751.
Windows 10 Laptop 21H2 inkl. aller Updates.

Wireguard auf der FB und Windows verbinden sich einwandfrei. Ich kann Netzlaufwerke und RDP verbinden. In der cmd kann ich die FB und Clients im Netzwerk anpingen, ebenso z. B. www.heise.de oder www.chip.de
Nur http Anfragen im Browser (Firefox und Bing) funktionieren nicht.

Könnte mir hier jemand einen heissen Tip geben??

Danke
 
Moinsen


HTTP:// auf die IPv4 oder fritz.box?
...wenn Ersteres klappt, aber Zweiteres nicht, haste keine DNS Auflösung für fritz.box.
Zeig mal ein kommandozeilenaufforderungswürdiges...
Code:
nslookup fritz.box
 
Ok, anscheinend wird die DNS fritz.box nicht aufgelöst. Die IP Adresse der Fritte kann ich anpingen
 

Anhänge

  • ip1.jpg
    ip1.jpg
    39.7 KB · Aufrufe: 29
10.0.0.1 ist die Fritzbox
 
anscheinend wird die DNS fritz.box nicht aufgelöst
Wozu braucht es diese Auflösung, wenn man mit dem Browser auf www.heise.de oder www.chip.de zugreifen will? Wenn ein ping dorthin funktioniert (so steht es in #1) und das unter Benutzung der beiden DNS-Namen, dann ist es schon mal nicht die Namensauflösung - selbst wenn die für die FRITZ!Box-Domain auf der anderen Seite des WG-Tunnels nicht funktionieren sollte. Solange der Browser dann auch "normales DNS" benutzt und nicht etwa DoH, ist das derselbe Mechanismus bei der Suche nach der richtigen IP-Adresse, wie beim funktionierenden ping.



WireGuard hat einen Paket-Overhead von 32 Byte, dazu kommen 8 Byte UDP-Header und 20 Byte IPv4-Header oder 40 Byte IPv6-Header. Hängt die FRITZ!Box an einem DSL-Anschluß mit PPPoE, kommen da noch einmal 8 Byte PPP-Header dazu.

Je nachdem, was da also an Internet-Anschlüssen und IP-Protokollen im Einsatz ist, darf der W10-Client für WireGuard nur eine MTU-Size von 1412 Byte benutzen, anstatt der 1420, die als Standard beim WG angenommen werden (weil der PPPoE-Overhead da nicht berücksichtigt ist und bei IPv6 dann die Pakete zu groß sind).

Symptom einer zu groß vermuteten MTU-Size sind u.a. langsam oder gar nicht ladende Seiten im Browser (weil zu große Pakete verloren gehen): https://www.google.com/search?q=wireguard+slow+page+loading+or+no+response+in+browser

Wenn da also IPv6 UND eine (deutsche) DSL-Verbindung genutzt werden, würde ich auf dem Windows-Client mal eine Zeile "MTU = 1412" (oder noch kleiner) in der Konfiguration hinzufügen. Ob die Voraussetzungen für dieses Problem bei Deiner Konfiguration zutreffen (dabei ist alles, vom PC über den lokalen Router (oder lokalen Mobilfunk im PC) bis zur entfernten FRITZ!Box zu betrachten) könnten, mußt Du selbst beurteilen.
 
Ist ein Telekomanschluss VDSL mit 100 MBit.
MTU habe ich auf 1412 eingestellt. Keine Verbesserung.
 
Ist ein Telekomanschluss VDSL mit 100 MBit.
Auf beiden Seiten? Oder auch noch derselbe?

Man kann auch mal die Developer-Tools des Browsers anwerfen ... dort werden die verschiedenen Phasen eines HTTP-Requests (DNS Resolution, Connection, TLS Setup, Sending, Waiting, Receiving) üblicherweise auch mit einem Timing dargestellt. Wenn das Senden funktioniert (zumindest das ohne TLS, denn dann sind die "simplen" HTTP-Requests entsprechend kurz, ebenso die ACK-Pakete, die eine erfolgreiche Übertragung eines Requests signalisieren - bei TLS käme noch der Handshake dazu und der kann auch schon mal größere Pakete produzieren und dann hängt es ggf. schon dabei) und nur keine Antworten kommen, dann würde ich NOCH EINMAL nach der MTU schauen und auch die Frage, welche IP-Version nun zum Einsatz kommt, spielt ja weiterhin eine Rolle. Wenn da schon DNS Resolution oder die TCP-Connection nicht klappen, dann lohnt sich die weitere Suche in dieser Richtung.

Ein VDSL-Anschluß bei der Telekom kann auch IPv6-Connectivität bereitstellen und wenn der LAN-Client (sprich der W10-PC) das dann ggü. IPv4 (im Falle von echtem Dual-Stack) bevorzugt (das entscheidet er schließlich selbst, wenn beides zur Verfügung stünde), dann wären die 1412 Byte MTU-Size zwar korrekt - aber wie ich auch schon schrieb, man KANN damit durchaus auch noch weiter heruntergehen (auch 1280 wäre eine Option, die sich begründen ließe - suche mal im Internet nach "1280" und "MTU" i.V.m. "WG") und ob das notwendig sein könnte, kann man nur dann beurteilen, wenn man die Umstände GENAU kennt.

Gerade dann, wenn die eine Seite der Verbindung keinen direkten Zugriff auf die "Leitung" hat (wie das hier beim W10-PC ja der Fall ist, solange da noch ein Router dazwischen wäre), ist es fast unmöglich, die wahre Konstellation automatisch zu ermitteln.

Daher ist die oben zitierte Auskunft zum Anschluß nicht wirklich hilfreich oder aussagekräftig - das sollte besser bzw. genauer und ausführlicher gehen. Wenn es um eine WG-Verbindung zu einer FRITZ!Box mit Labor-Firmware geht, muß man eben sogar IPv6 als Transport-Protokoll in Erwägung ziehen. Das sollte aber m.W. in der FRITZ!Box stehen, wenn sich der WG-Client erfolgreich verbunden hat mit der Box.

Ich komme mir zwar ab und an auch etwas merkwürdig vor, wenn ich nur noch von MTU schreibe bei solchen Problemen (und das dann so aussieht, als wäre für den Mann mit dem Hammer automatisch alles ein Nagel), aber wenn die Symptome passen, wäre es ja auch blöd, wenn man - nur um der Diversität willen bei Vorschlägen zur Lösung von Problemen - jetzt auf etwas vollkommen anderes abstellen würde. Ansonsten würde ich natürlich auch empfehlen, einfach mal das Netzteil oder das WLAN-Kabel zu tauschen. Ausgetrocknete Elkos werden es aber bei einer 7590 vermutlich eher nicht sein. :cool:
 
10.0.0.1 ist die Fritzbox
Und Die ist auch (vermute ich ganz stark) der einzige Nameserver der fritz.box auflösen kann.
Dann ist das Kommando für nslookup diesen Nameserver zu nutzen/checken: nslookup fritz.box 10.0.0.1
...und dein (WG?) Netzwerkadapter bräuchte den dann folglich als DNS-Server und (Internet) Gateway.
Manche wollen das so, Manche nicht.
...kann ja auch ein Sicherheitsgewinn sein einen Router nicht* über eine standard IP/Name zu erreichen.


* Die FRITZ!Box bietet selber einen zwei: UDP/192.168.180.1:53 und UDP/192.168.180.2:53
Code:
$ nslookup fritz.box 192.168.180.1
Server:        192.168.180.1
Address:    192.168.180.1#53

** server can't find fritz.box: NXDOMAIN

$ nslookup ip-phone-forum.de 192.168.180.1
Server:        192.168.180.1
Address:    192.168.180.1#53

Non-authoritative answer:
Name:    ip-phone-forum.de
Address: 172.67.68.104
Name:    ip-phone-forum.de
Address: 104.26.2.172
Name:    ip-phone-forum.de
Address: 104.26.3.172
Name:    ip-phone-forum.de
Address: 2606:4700:20::681a:2ac
Name:    ip-phone-forum.de
Address: 2606:4700:20::681a:3ac
Name:    ip-phone-forum.de
Address: 2606:4700:20::ac43:4468

$ nslookup s.to 192.168.180.1
Server:        192.168.180.1
Address:    192.168.180.1#53

s.to    canonical name = notice.cuii.info.
Name:    notice.cuii.info
Address: 167.233.14.14
Die nutzen wohl nur die DNS-Server deines Providers ( vorsorglich zensiert oder nicht :cool: )
...auch bei aktivierten Benutzerdefinierten und/oder DoT.
 
Zuletzt bearbeitet:
Öhm, sorry. Mir ist das zuviel fachchinesisch und ich blicke nicht mehr durch. Könnte es bitte mal jemand in DAU Deutsch übersetzen?

Derzeit baue ich die Verbindung wie folgt auf:
Smartphone (Huawei Mate 20 Pro, Android 10, Emui 11) Hotspot aktiviert. LTE 25 MBit via Klarmobil. An diesen Hotspot meldet sich der Laptop (Windows 10 21H2 inkl. aller Updates) an. Darüber kann ich normal ins Internet (ohne WireGuard).

Aufbau per WireGuard funktioniert. RDP, Netzwerkfreigabe und anpingen von Websites, Clients und Frtitzbox funktionieren.
Wenn ich den Hotspot vom Tablet (Huawei Tablet, Android 9) nutze und hier WireGuard nutze, funktioniert alles wie es soll.
Ebenso funktioniert WireGuard im LTE seitens des Smartphones.

Somit ist meine Vermutung, dass es am Laptop liegt. Und wo dort "der Hase im Pfeffer" liegt ist mir fraglich. Die MTU habe ich auf 1492 gestellt, WLAN Adapter ist komplett auf Auto gestellt (kein feste IP u. DNS).
 
Die MTU habe ich auf 1492 gestellt
Bleibt die Frage, wo da der Tippfehler liegt ... in dem Text für diesen Beitrag oder doch schon in der Konfigurationsdatei. Der Standard bei WG wäre 1420 - den jetzt um 72 zu ERHÖHEN, ergibt so überhaupt keinen Sinn.

Die Frage, ob da nun IPv6 oder IPv4 verwendet wird, ist auch weiterhin offen - wo man das finden sollte (wenn man es sich ansonsten nicht zutraut, das auf dem W10-PC zu finden), habe ich oben schon ausgeführt.

Auch beinhaltete meine Frage ja nicht nur die eine Seite der Verbindung, wo der Laptop eingesetzt wird (auch wenn Du Deinerseits das Problem klar dort sehen willst, kann es durchaus von "Besonderheiten" der Gegenstelle, wie z.B. der PPPoE-Kapselung bei den in D üblichen DSL-Anschlüssen, beeinflußt werden), sondern auch die Angaben, was denn auf der FRITZ!Box-Seite vorhanden ist (auch hier die Frage, ob IPv4 UND IPv6 zur Verfügung stehen - DS-Lite wird es ja eher nicht sein, wenn Einwahl überhaupt möglich ist).

Bis hin zu der Frage, über welchen DynDNS-Service die Adresse der Ziel-(FRITZ!)Box eigentlich ermittelt wird und ob dort A- UND AAAA-Einträge hinterlegt sind, aus denen der WG-Client frei wählen kann.

Und das ist auch nicht nur reine Neugierde von meiner Seite ... für eine klare Antwort bzw. einen sinnvollen Tipp (der nicht nur auf eigenem Raten basiert) braucht man diese Infos nun mal und egal, für wen Du die dann zusammensuchst - Du wirst (vermutlich) nicht umhinkommen, das zu sammeln.

Außer Du willst die diversen Irrungen und Wirrungen mitmachen, die sich zwangsläufig ergeben, wenn die Hilfeleistenden nur raten können ... und dabei fällt mir dann auch gleich wieder ein, daß Du natürlich die Änderung der MTU-Size wieder rückgängig machen solltest, wenn sie TATSÄCHLICH keine Auswirkungen zeitigen konnte (man kann das ja dann auch noch überprüfen, ob die eigene Änderung auch Wirkung entfaltete - zu häufig gingen vermeintliche Änderungen auch schon daneben und die dennoch daraus gezogenen Schlußfolgerungen führten dann in die Irre).

Die Empfehlung, die von mir bereitgestellte Google-Suche doch einfach mal selbst zu unternehmen (ggf. kannst Du das ja auch auf Deutsch machen, was naturgemäß aber die Anzahl der Treffer einschränken wird), halte ich dennoch aufrecht - ebenso wie die Erweiterung der Bedingungen in #8.

EDIT:
Und um das noch einmal ganz, ganz deutlich zu machen, worin der entscheidende Unterschied zwischen der WG-Verbindung vom PC aus und der WG-Verbindung von allen anderen beschriebenen Geräten aus liegt: Der PC ist das einzige Gerät in den ganzen Beschreibungen, der seinerseits die "physikalische Verbindung" (über LTE) nicht selbst herstellt, sondern seine Internet-Verbindung über ein anderes Gerät nutzt - sowohl das Smartphone als auch das Tablet benutzen nach Deiner Beschreibung jeweils ihre eigenen Verbindungen ins Internet und KENNEN daher die genauen Umstände (welche IP-Protokolle stehen auf welchem Weg zur Verfügung) auch selbst, während das alles dem PC "unbekannt" ist.

Diese beiden Geräte können auch - als Router - nicht in den WG-Traffic vom PC eingreifen ... der ist schließlich ABSICHTLICH verschlüsselt und das Einzige, was die jeweiligen Router davon sehen können, sind die IP-Adressen und die Portnummern. Bei WG gibt es nicht mal die eine "fixe" Portnummer, aus der man mit einiger Wahrscheinlichkeit darauf schließen könnte, daß es sich da um verschlüsselte Kommunikation handelt.
 
Zuletzt bearbeitet:
Ok, anscheinend wird die DNS fritz.box nicht aufgelöst
Wie soll der Name aufgelöst werden, wenn das System, welche die Auflösung bekommen will, keinen DNS-Server eingetragen hat, der befragt werden kann?

In dem Bild steht doch
Code:
nslookup fritz.box
DNS request timed out.
     timeout was 2 seconds
server:   UnKnown
Das System, welches du als DNS-Server nach dem Namen fragen willst, sagt, dass es kein DNS-Server ist.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.