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 einen alternativen Browser verwenden.
Fritzbox - kein ausgehendes WireGuard via UDP 53 möglich?
Läuft Wireguard direkt auf dem Server oder in einem Container oder ähnlichem? Dass Wireguard über Fritzbox Gastnetz nicht geht ist eigentlich immer der Fall, da UDP Verkehr komplett gesperrt ist, das würde ich also ausklammern.
Wie sieht es testhalber auf anderen Ports aus? Kannst du deine Configs posten, mit zensierten Schlüsseln?
WireGuard läuft via pfSense. Konfigurationsfehler auf Server-Seite würde ich ausschließen, da
Verbindung über WiFi-Hotspot von meinem Smartphone -> WG-Tunnel funktioniert
Verbindung über WiFi-Netzwerk von meinem Router -> WG-Tunnel bekommt keinen Handshake
Ändere ich den WireGuard-Port auf Server-Seite, klappt der Handshake sofort auch via FritzBox.
D.h. es liegt entweder an der FritzBox, oder vlt. sogar dem Internet-Provider?
Es sind keinerlei Filter in der Fritzbox hinterlegt, die Clients sind alle unlimitiert.
Wenn UDP 53 gesperrt wäre, könnte man am PC auch keinen Public DNS verwenden, also zB 8.8.8.8. Das kann man ganz einfach testen, indem man mit nslookup computerbase.de 8.8.8.8 einen DNS-Query an den google-dns schickt.
Bevor du vorschnell die Fritzbox als Ursache definierst, untersuche das Problem am Server genauer. Das heißt: WireShark / tcpdump. Prüfe dort was reinkommt und ggfs wieder rausgeht. Am Ende ist es womöglich gar nicht die Fritzbox, sondern dein Server.
Auch auf der Fritzbox kann man entsprechende Mitschnitte erstellen und per Wireshark analysieren. Hier solltest du 2x Mitschnitte anfertigen. https://fritz.box/html/capture.html bringt dich dahin. Ich empfehle das "Hintergrundrauschen" zu minimieren, also nicht benötigte Geräte auszuschalten, keine anderen Anwendungen laufen lassen etc. damit der Mitschnitt nicht zu groß wird.
Anschließend musst halt prüfen ob auf der LAN bzw. WLAN Schnittstelle die Wireguard Pakete vom Client ankommen und ob diese auch wieder die Fritzbox verlassen in Richtung Internet. Wenn beides der Fall ist, dann hast die Fritzbox als Übeltäter ausgeschlossen. Wenn dann zusätzlich keine Pakete am Server ankommen, dann liegt es irgendwo zwischen deinem ISP und dem Netcup Server.
Wenn Pakete zur Fritzbox ankommen aber nicht raus gehen, dann musst entsprechend da weiter suchen.
Wenn UDP 53 gesperrt wäre, könnte man am PC auch keinen Public DNS verwenden, also zB 8.8.8.8. Das kann man ganz einfach testen, indem man mit nslookup computerbase.de 8.8.8.8 einen DNS-Query an den google-dns schickt.
DNS geht doch als Fallback auf TCP 53, also das kann man mit den meisten öffentlichen DNS Servern so nicht testen.
Die Pakete die Wireguard via Port 53 verschickt sind natürlich nicht DNS Konform, ob die irgendwo auf der Strecke gefiltert werden?
Als Workaround habe ich ne NAT Regel auf dem Server eingerichtet die UDP443 auf UDP53 lenkt. Somit kann das Heimnetzwerk via UDP443 sich verbinden, alle anderen Clients via UDP53.
Edit:
Habe das auch soeben mit dem Netcup-Server getestet: UDP 53 Pakete von Wireguard via meiner Heimnetz-IP kommen nicht am Server an, keinerlei Log-Einträge. Werden also irgendwo gefiltert.
Edit 2:
Stelle ich die DNS-Server auf meine Netcup-IP, sehe ich eingehende UDP 53 Pakete (die natürlich nicht beantwortet werden, da hier Wireguard zuhört).
D.h. irgendwo werden nicht reguläre DNS-Pakete blockiert ...
Verschwörungstheoretiker würden vermuten, der Internetprovider liest alle DNS-Anfragen an Server mit, und verwirft solche die er nicht auslesen kann 😅
Dann wie @snaxilian beschrieben hat auf der Fritzbox ein capture machen. Wenn's da rausgeht, kannst du nichts tun, weil's dann irgendwo zwischen dir und dem Server hängenbleibt.
Womöglich ist es gar die Flood Protection des Rechenzentrums, die UDP 53 hier blockt. Bei DNS ist es nicht unüblich, dass Rate Limits komfiguriert sind, da DNS - richtig angewendet - für sehr effektive DoS-Attacken missbraucht werden kann, sogenannte DNS Amplification Attacks. Ggfs wird WireGuard via DNS sozusagen als DoS Angriff abgefangen bevor es überhaupt zu deinem Server kommt. Teste mal einen anderen Port.
UDP 443 wäre ein möglicher Workaround, das ist richtig. Dabei muss man sich aber darauf verlassen, dass die restriktive Firewall im Hotel, o.ä. https lediglich auf der Portnummer 443 filtert, also TCP und UDP. Letzteres hat mit https allerdings nichts zu tun und eine sauber konfigurierte Firewall würde UDP 443 ebenfalls blocken.
Wenn alle Stricke reißen, bleibt noch OpenVPN. Zwar ist OpenVPN nicht so performant wie WireGuard - u.a. weil es single threaded ist - aber dafür hat man sowohl beim Port als auch beim Protokoll freie Hand, TCP 443 wäre also kein Problem und könnte nur durch ressourcenintensives DPI geblockt werden.
Ergänzung ()
x.treme schrieb:
Als Workaround habe ich ne NAT Regel auf dem Server eingerichtet die UDP443 auf UDP53 lenkt.
Ich persönlich würde die Dienste immer auf dem Standardport laufen lassen und etwaige Portwechsel sowieso nur via NAT machen. Das erleichtert zum einen die Migration bzw Reinstallation des Dienstes, weil man nix weiter am Dienst rumschrauben muss, und zum anderen kann man nach Belieben auch mehrere NAT-Regeln an zentraler Stelle für die externen Ports einrichten. Außerdem kann man den externen Port so binnen Sekunden ändern, ohne den Dienst umkonfigurieren und neustarten zu müssen.
Wer ist denn der ISP, der rosa Riese? Denen traue ich fast alles zu.
Kannst Du sehen, welchen Source-Port der Client nutzt? Sollte random sein und vermutlich auch keine Rolle spielen.
Liefere uns bitte bloß keine Details sonst könnten wir dir aus Versehen doch noch helfen.
An welchem Interface hast denn den Mitschnitt gemacht? Mache doch einmal nur auf LAN/WLAN Seite dann solltest du die eingehenden Pakete ja sehen und dann noch einen nur auf WAN, da sollten genau diese Pakete ja als ausgehende Pakete zu sehen sein. Ist das bei beidem der Fall dann kontaktiere deinen ISP. Wenn nicht, ist entweder das falsche Interface gewählt worden oder die Fritzbox verwirft diese Pakete weil sie nach fehlerhaftem DNS aussehen.
War die Routing-Schnittstelle, dachte die Internet-Schnittstelle loggt nur die eingehenden Pakete und wäre deswegen irrelevant ...