Portforwarding Rule wird nicht angewandt

Es gibt 6 Antworten in diesem Thema, welches 2.401 mal aufgerufen wurde. Der letzte Beitrag () ist von iTweek.

    Einen wunderschönen guten Abend und ein frohes neues Jahr erstmal.


    Für mich startete das Jahr leider nicht so fröhlich, da sich mit einem automatischen Firmwareupdate der USG3P um 0.05Uhr mein gesamtes Netzwerk verabschiedete. Leider war ich auch blöd genug, kein Backup zu haben, daher auch kein Mitleid mit mir.

    Soweit so schlecht, ich machte mich also an die Widerherstellung aller Einstellungen.


    Folgender IST-Zustand des Netzwerks:


    Telekom VDSL mit dynamischer IPv4 -> DreyTek Vigor 160 (bridged) -> USG3P -> US24 Switch, von hier aus ist es fast irrelevant.

    Ich betreibe einen Proxmox host, der sowas wie eine Nextcloud, PiHole, Unifi Controller, usw. beinhaltet. Unteranderem ebenfalls eine VM, welche als Docker Host NGINX Proxymanager zum Einsatzbringen soll (IP: 192.168.67.132).

    Bis zu dem verhängnisvollen Verlust meiner Konfiguration lief es so, dass ich im Unifi Controller (Legacy Interface) zwei Portforwarding Rules hatte. Diese verwiesen auf 192.168.67.132:80 und 192.168.67.132:443 (Let's Encrypt SSL Zertifikate). Von hier aus konnte ich dann über meine Domain, welche per DynDNS im Controller hinterlegt war und per CNAME Einträgen auf unterschiedliche Namen hören konnte, die Weiterleitung an die weiteren VMs/LXC steuern.


    Beispielsweise:

    • nextcloud.domain.com -> 192.168.67.132:443 -> an eine interne IP, z.B. 192.168.67.32
    • pihole.domain.com -> 192.168.67.132:443 -> an eine andere interne IP, z.B. 192.168.67.21

    Und so weiter und so fort. Diese Aufgabe übernimmt wie gesagt der Proxymanager.


    Nun dachte ich würde alles wie bisher funktionieren, doch das Szenario stellt sich wie folgt dar:

    Ich habe meinen DynDNS Eintrag wieder hergestellt (WAN IP wird korrekt übernommen).

    Ich habe beide Portforwarding Regeln wieder erstellt für Port 80 und 443 auf die 192.168.67.132.

    Wenn ich jetzt allerdings ein SSL Zertifikat erstellen möchte, wird mir eine Fehlermeldung angezeigt, dass angeblich hinter dieser Domain nicht der NGINX Proxymanager geschaltet wäre.

    Erst dachte ich daran, dass es hier ein Problem bei der VM, im Docker oder der Konfiguration des Proxymanager vorhanden wäre, bis ich nach stundenlangem Suchen die einfachste Methode gecheckt habe.


    Über einen Portchecker einer externen IP (Handy im Mobilnetz), habe ich geprüft ob die beiden Ports 80 und 443 überhaupt geöffnet sind. Es stellt sich heraus (warum auch immer), dass nur Port 80 erreichbar ist und Port 443 als "closed" erscheint.

    Wo liegt das Problem?


    Ich habe bereits mehrfach einen Powercycle am USG3P, am Switch, am Unifi Controller, am Proxymanager und Proxmox host unternommen, es brachte jedoch keine Besserung. Auch eine Aktivierung und Deaktivierung der Portforwarding Regel oder eine Änderung auf eine andere interne IP (192.168.67.45) brachte nichts. Der Port 443 wird immer noch als closed angezeigt.


    Ein sudo tcpdump -n -i eth0 tcp port 443 per SSH auf der USG3P ergibt leider gar keinen Traffic, ebenso wenig wie auf Port 80.

    Über den Befehl tail -f /var/log/messages | grep "WAN_IN-*rule number* konnte ich folgende Ergebnisse erzielen:


    Code
    Port 443: [WAN_IN-3004-A]IN=pppoe2 OUT=pppoe2 MAC= SRC=185.213.155.252 DST=192.167.67.132 LEN=52 TOS=0x00 PREC=0x00 TTL=122 ID=62328 DF PROTO=TCP SPT=62354 DPT=443 WINDOW=65535 RES=0x00 SYN URGP=0

Port 80: [WAN_IN-3003-A]IN=pppoe2 OUT=eth1 MAC= SRC=198.199.98.246 DST=192.168.67.132 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=23045 DF PROTO=TCP SPT=41065 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0


    Leider fällt es mir schwer nachzuvollziehen, wieso bei OUT= einmal das WAN Interface (also ppoe2) und einmal das LAN Interface (eth1) als Ziel genommen wird.

    Hier bin ich nun am Ende meines Lateins und benötige Hilfe, damit der Wife Acceptance Factor nicht in den vollkommenen Negativbereich vorstößt.


    Habe ich noch irgendwelche Informationen vergessen die benötigt würden?


    Edit:

    Vergessen zu erwähnen

    • USG3P FW 4.4.56.5449062
    • Unifi Controller (on Linux) FW 6.5.55_16678
    • US-24 Switch FW 5.76.7.13442

    2 Mal editiert, zuletzt von hoyohayo () aus folgendem Grund: Ergänzung an Informationen und Korrektur der Beispiele von Weiterleitung

    Nein natürlich nicht, sorry für die nicht ausführliche Erklärung.


    Ich leite möchte https://nextcloud.domain.com auf 192.168.67.132:443 und http://nextcloud.domain.com auf 192.168.67.132:80 leiten. Alles weitere im internen Netz übernimmt der NGINX Proxymanager, der hier als Reverseproxy dient und der Traffic im lokalen Netz ruhig unverschlüsselt sein darf. Decatec Nextcloud mit Reverseproxy hier wurde es zum Beispiel sehr ausführlich beschrieben. Nur konfiguriere ich den Reverseproxy eben nicht händisch sondern mit dem Proxymanager.


    Also alles was hinter der 192.168.67.132 passiert, soll nicht weiter von Belang sein, denn ich habe das Problem, diese per 443 zu erreichen.

    Wenn ich es richtig sehe hast du bei 443 einen Zahlendreher drin.

    Du möchtest auf 192.168.67.132:443, ABER du hast dort dzt eingetragen 192.167.67.132



    Da sollte 192.168.67.132 stehen und nicht wie dzt 192.167.67.132

    ZOMFG...


    Und ich hab mich wie bekloppt zu Tode gesucht. Ich danke dir auf Knien! Das war doch wirklich die Lösung.

    Danke für diesen unglaublich wichtigen Hinweis und vielen Dank für das Lesen bis ins kleinste Detail.


    iTweek Vielen Dank auch für deine Hilfe, tatsächlich funktioniert die lokale weiterleitung ganz ohne Probleme. Das hätte ich vielleicht noch in meinem Original Post dazu schreiben sollen. Von meinen lokalen Maschinen komme ich überall hin.