WireGuard über FRITZ!Box 6670, Self-hosted Dienste mit HSTS-/Zertifikatsfehler

Hallo liebes Forum,

ich habe ein Problem mit meinem Heimnetzwerk und bin inzwischen ziemlich ratlos. Vielleicht hat jemand eine Idee, woran es liegen könnte.

Mein Setup​

  • Router: FRITZ!Box 6670 Cable (Fritz OS 8.25)
  • Server: Raspberry Pi 5 mit Debian 13 Lite OS
  • DNS: AdGuard Home auf dem Raspberry Pi
  • Reverse Proxy: Nginx Proxy Manager
  • Cloud: Nextcloud AIO (Mit aktuellen PHP Sicherheitspatch)
  • VPN: WireGuard über die FRITZ!Box
Alles in Docker
Meine selbst gehosteten Dienste sind über eigene Domains erreichbar und laufen über den Nginx Proxy Manager.

Das Problem​

Sobald ich mich mit dem Pixel 11 (unter iOS tritt das Problem nicht auf) per WireGuard zur FRITZ!Box verbinde, kann ich keine der gehosteten Dienste mehr über die Domains erreichen.

Im Browser erscheint unter anderem folgende Meldung:
Sie können diese Website im Moment nicht besuchen, da die Website HSTS verwendet.
Teilweise wird auch ERR_CERT_AUTHORITY_INVALID angezeigt.
Dasselbe Problem tritt mit DAVx auf Android auf. Ohne aktive WireGuard-Verbindung funktionieren die Dienste über ihre Domains normal. Andere Verbindungen und Dienste funktionieren über WireGuard problemlos. Das Problem betrifft die selbst gehosteten Dienste, die über Domains aufgerufen werden.

Bisherige Tests​

1. DNS-Auflösung
Die Domain wird sowohl mit als auch ohne WireGuard auf dieselbe öffentliche IPv4-Adresse aufgelöst.
Sowohl der DNS der FRITZ!Box als auch der lokale DNS der Fritzbox sind mit AdGuard Home konfiguriert. Im Abfrageprotokoll von AdGuard wird die Anfrage korrekt aufgelöst. Als Upstream wird Quad9 über HTTPS verwendet.
Auch bei einer Prüfung über den Domainnamen wurde die Zertifikatskette erfolgreich verifiziert. Das Zertifikat stammt von Let's Encrypt.

3. Nginx Proxy Manage
Der Nginx Proxy Manager verwendet für Nextcloud AIO folgenden Upstream: (es geht leider nicht anders, da die AIO ihr eigenes Netzwerk Aufbaut)

http://nextcloud-aio-apache:11000

In den bisherigen Logs gab es bei einzelnen Verbindungsversuchen HTTP-400-Einträge ohne erkennbare Weiterleitung an den Upstream.

Meine Vermutung​

Ich vermute inzwischen ein Problem mit dem Routing oder NAT-Loopback der FRITZ!Box, da die Domains auf die öffentliche IP zeigen und der Zugriff aus dem eigenen Heimnetz über WireGuard offenbar anders behandelt wird. (Komischerweise tritt das Problem nicht unter iOS auf)

Ganz sicher bin ich mir dabei allerdings nicht, insbesondere weil der Browser einen Zertifikatsfehler meldet.

Meine Fragen​

  • Kann die FRITZ!Box 6670 bei WireGuard-Verbindungen Probleme mit dem Zugriff auf eigene Dienste über die öffentliche IP und Domain verursachen?
  • Könnte es stattdessen ein Problem mit der DNS-Konfiguration der FRITZ!Box oder der TLS-Verbindung über WireGuard sein?
  • Welche Tests würdet ihr als Nächstes durchführen, um die Ursache eindeutig einzugrenzen?


Anfänglich gab es unter iOS auch die gleichen Probleme, ich habe dann den HTTPS Zugriff der Fritzbox aus dem Web. Mit der Kryptischen MyFritz Domain deaktiviert dann ging es auch unter iOS 1A.

Ich möchte nicht auf Verdacht an der Nextcloud-Konfiguration Herumhämmern, solange nicht klar ist, wo das Problem liegt.

Vielen Dank für eure Hilfe!
 
Zuletzt bearbeitet:
Habe bei ähnlicher Konstellation (Nextcloud Docker, aber von linuxserver.io, hinter nginx Reverse Proxy mit HsTS und WG VPNs 0 Probleme. Wo terminiert die SSL Verbindung? Vermutlich auf dem Reverse Proxy, hat der auch das Zertifikat? Ich sehe weniger bei dem WG Tunnel das Problem, außer du Routest alles dadurch. Dann könnte es Probleme geben. Kann aber auch heute nicht mehr nach schauen, da unterwegs
 
Weitere Fragen zur Eingrenzung: Greifst du bei aktivem WireGuard über den Tunnel auf deine öffentliche IP zu oder läuft dieser Zugriff am Tunnel vorbei? Erfolgt die HTTPS-Verbindung dabei über IPv4 oder IPv6? Dieselbe aufgelöste IPv4-Adresse sagt noch nicht, welche Adresse tatsächlich verwendet wird.

Hat dein Kabelanschluss Dual Stack mit eigener öffentlicher IPv4 oder DS-Lite?

Und für welche Domain ist das Zertifikat ausgestellt, das dir im Fehlerfall tatsächlich präsentiert wird? Wer ist der Aussteller? Damit ließe sich eingrenzen, ob du überhaupt beim Reverse Proxy landest oder beispielsweise auf der HTTPS-Oberfläche der FRITZ!Box.
 
conf_t schrieb:
Wo terminiert die SSL Verbindung? Vermutlich auf dem Reverse Proxy
Ja genau
conf_t schrieb:
hat der auch das Zertifikat?
Ja
conf_t schrieb:
außer du Routest alles dadurch.
Ich Route den gesammten Trafic am Handy durch WireGuard
conf_t schrieb:
Greifst du bei aktivem WireGuard über den Tunnel auf deine öffentliche IP zu
Ja, genau
conf_t schrieb:
Erfolgt die HTTPS-Verbindung dabei über IPv4 oder IPv6?
Nextcloud AIO und Vaultwarden werden mit dem NPN über IPv4 geroutet
conf_t schrieb:
Hat dein Kabelanschluss Dual Stack mit eigener öffentlicher IPv4 oder DS-Lite?
Eine Öffentliche Dynamische IPv4 Adresse, ohne Dual Stack
conf_t schrieb:
Wer ist der Aussteller?
Let's-Encrypt
conf_t schrieb:
beispielsweise auf der HTTPS-Oberfläche der FRITZ!Box.
Über WireGuard läuft alles eigl. 1A und die GUI der FB lässt sich aufrufen, über HTTP. Nur die Self Hosted Dienste mit https machen probleme.
conf_t schrieb:
Und für welche Domain ist das Zertifikat ausgestellt,
Das ist die Fehlermeldung von DAVx⁵ (Siehe Bild) ich verstehe nicht was die FB da zu suchen hat:

WhatsApp Image 2026-10-23 at 23.39.35.jpeg
 
Ok, die Verbindung terminiert in dem Fall offensichtlich auf der FB und nicht auf dem Reverse Proxy.

Kabelanschlüsse sind dafür bekannt mit IPv6 zu laufen und einer nicht öffentlichen IPv4 oder einer extra bestellten öffentlichen IPv4 (meist sog. Business Verträge).

Sieht für mich aktuell nach einer IP oder DNS Thematik aus. Welche IP wird die beim Auflösen am Handy angezeigt für deine Domäne (gibt Netzwerk Apps dafür). Und die Route?
 
Ich löse das bei mir über die lokale DNS-Auflösung. Im VPN nutze ich die DNS-Server meines LANs. Dort zeigt meine Nextcloud-Domain auf die lokale IP des Reverse Proxys statt auf die öffentliche IP.

Das kannst du mit deinem AdGuard Home genauso machen: Unter „Filter → DNS-Umschreibungen“ den vollständigen Hostnamen deiner Nextcloud, ohne https:// oder Pfadangabe, eintragen. Als Ziel kommt die LAN-IP rein, unter der dein Nginx Proxy Manager auf HTTPS-Port 443 erreichbar ist. Für Vaultwarden entsprechend wiederholen.

Entscheidend ist anschließend, dass die DNS-Anfragen vom Handy bei aktivem VPN tatsächlich über AdGuard laufen. Das kann direkt geschehen oder über die FRITZ!Box, wenn diese an AdGuard weiterleitet. Laut deiner Beschreibung scheint das bereits der Fall zu sein.

Danach prüfen, ob die Domain am Handy auf die eingetragene LAN-IP aufgelöst wird. Im AdGuard-Abfrageprotokoll sollte die DNS-Umschreibung erkennbar sein.

Du verwendest weiterhin dieselben URLs. Zertifikat und HSTS bleiben damit unverändert nutzbar. Der Zugriff läuft dann über das VPN direkt zum Reverse Proxy und benötigt keinen Umweg über die öffentliche IP samt NAT-Loopback.
 
  • Gefällt mir
Reaktionen: qiller
Jop, Split-DNS benutzen wir auch. Das funktioniert einfach immer, wenn die korrekten DNS-Server übergeben werden. Mit NAT-Loopback hatte ich auch immer irgendwelche Probleme (schon zu lange her, welche das waren).

Ansonsten könnte es auch an irgendwelchen Smartphone-Einstellungen liegen, wenns mitm iPhone geht, aber mit Android nicht. Vlt. irgendwelche Datenschutz-Settings? Oder das IPv6 vs. IPv4 Thema. Vlt. bekommt das iPhone über seinen Provider nur IPv4 und kein IPv6. Und das Android bekommt beides.
 
qiller schrieb:
wenns mitm iPhone geht
Mit dem iPhone ist mir aufgefallen das iOS trotz VPN die DNS Server von Telekom nutzt (Mobile Daten ist bei mir in dem fall Telekom) Mit Inexio oder 1&1 das gleiche, iOS verwendet teils immer die DNS server der internet anbieter in dessen netz sich das iPhone befindet.

Das sieht für mich danach aus als würde das iPhone nicht alle DNS anfragen durch den VPN leiten.
Ich habs mit dem Tool getestet: https://dnscheck.tools/
Ergänzung ()

conf_t schrieb:
Ich löse das bei mir über die lokale DNS-Auflösung
Ich teste das gerade mal
Ergänzung ()

conf_t schrieb:
Ich löse das bei mir über die lokale DNS-Auflösung
Es Funktioniert zwar über VPN... aber ich kann ohne VPN nur noch dienste erreichen die auf eine Domain zeigen, SSH ist nicht mehr erreichbar AdGuard ist auch nicht mehr erreichbar, sogar die Fritzbox ist local nicht mehr erreichbar.

Das scheint jetzt ein Windows problem zu sein, kurios. An den Handys gehts

SORRY Layer 8 Fehler, Windows hat sich mit dem iPhone hotspot verbunden, kein wunder das es dann nicht ging.


Ergänzung ()

ABER diese Meldungen sind neu, vorher hatte ich nur belangloses was die iOS App von NC AIO betraf:

Screenshot 2026-10-24 122136.png
Screenshot 2026-10-24 122145.png
 
Zuletzt bearbeitet:
Da weiß ich auch mit nicht anzufangen. Die sind von der Adminoberfläche der NC? Wenn bei mir mal was steht, womit ist nichts anfangen kann Google ich danach oder frage die KI.
 
conf_t schrieb:
Da weiß ich auch mit nicht anzufangen.
Ich habs anders gelöst. ich habe auf dem Raspi 5 WGDashboard eingerichtet, darüber läuft das VPN 1A. Ich habe über dieses VPN Internet, meine Dienste sind über meine Domain aufrufbar, ohne irgendwelche HSTS oder 400 Fehler. Wiedereinmal durfte ich feststellen das Fritzboxen gerne ihr eigenes ding machen.....

Ich habe für mich persönlich festgestellt das WireGuard der Fritzbox Müll ist
 
Vodafone Glasfaser
Zurück
Oben