Trotz Reverse Proxy: Connection refused from the non-local address

[heikoh81]

Hallo zusammen,

ich habe eine fhem-Instanz (debian, nicht dockerized) auf einem VPS laufen, der auch als Mail-, Web- und VPN-Server bei mir fungiert.
Fhem ist hinter einem Nginx-Reverse-Proxy mit BasicAuth geschaltet:

Code Auswählen Erweitern

    location /fhem {
        set $my_http_upgrade "";
        set $my_connection "Connection";
        if ($http_upgrade = "websocket") {
          set $my_http_upgrade $http_upgrade;
          set $my_connection "upgrade";
        }
        proxy_set_header Upgrade $my_http_upgrade;
        proxy_set_header Connection $my_connection;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host:$server_port;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_read_timeout 2073600;
        proxy_buffering off;
        proxy_pass http://localhost:8083/fhem;
auth_basic "Restricted Content";
auth_basic_user_file /etc/nginx/.htpasswd;
    }

Das funktioniert auch, d.h. bei aufruf der URL kommt eine BasicAuth abfrage.

Da BasicAuth ja nicht mehr so Stand der Technik ist, habe ich vor Monaten einen dockerized NginxProxyManager mit Authelia davor geschaltet, um so eine Art SingleSignOn für meine Applikationen zu haben.
Das funktioniert auch alles, inklusive Fail2Ban usw., und dennoch habe ich das hier im log:

Code Auswählen Erweitern

2025.12.06 11:58:40 1: Connection refused from the non-local address 93.174.95.106:59434, as there is no working allowed instance defined for it
2025.12.06 11:58:40 1: Connection refused from the non-local address 93.174.95.106:59460, as there is no working allowed instance defined for it
2025.12.06 11:58:41 1: Connection refused from the non-local address 93.174.95.106:59574, as there is no working allowed instance defined for it
2025.12.06 11:58:41 1: Connection refused from the non-local address 93.174.95.106:59600, as there is no working allowed instance defined for it
2025.12.06 11:58:41 1: Connection refused from the non-local address 93.174.95.106:59658, as there is no working allowed instance defined for it

Ich verstehe überhaupt nicht, wie das überhaupt zu fhem durchkommt. fhem sollte nur port 8083 offen haben, warum reagiert das überhaupt auf die hier gezeigten ports?

Code Auswählen Erweitern

define WEB FHEMWEB 8083 global
setuuid WEB 65.......
attr WEB JavaScripts codemirror/fhem_codemirror.js
attr WEB csrfToken none
attr WEB editConfig 1
attr WEB longpoll 1

Ich habe jetzt mal das "global" testweise entfernt & werde das Log beobachten.
Dennoch verstehe ich nicht, wieso fhem überhaupt auf die ganzen Ports lauscht.

Viele Grüße,
Heiko

[betateilchen]

Diese ports im 50.000er Bereich sind temporäre interne Verbindungen, die von FHEM benötigt werden.
Die sieht man prinzipiell in jedem FHEM, wenn man "list TYPE=FHEMWEB" eingibt:
Diese Verbindungen entstehen und verschwinden von alleine wieder.

Bei mir sieht das aktuell beispielsweise so aus:

Code Auswählen Erweitern

web_longpoll
web_longpoll_192.168.123.162_59839
web_longpoll_192.168.123.162_59840
web_longpoll_192.168.123.162_59842
web_longpoll_192.168.123.162_59843
web_longpoll_192.168.123.162_59844


[heikoh81]

Danke für deine schnelle Antwort.
Vorweg: Seit ich in der DEF 8083 global auf nur 8083 geändert habe, gibt es keine solchen Log-Einträge mehr.

Bzgl. der 50000er-Ports:
Ich habe leider auch Zugriffe bei niedrigeren Ports, sieht irgendwie nach Portscans aus:

Code Auswählen Erweitern

2025.12.01 00:51:54 1: Connection refused from the non-local address 79.124.49.90:50124, as there is no working allowed instance defined for it
2025.12.01 01:26:29 1: Connection refused from the non-local address 162.142.125.125:1922, as there is no working allowed instance defined for it
2025.12.01 01:26:29 1: Connection refused from the non-local address 162.142.125.125:1942, as there is no working allowed instance defined for it
2025.12.01 01:26:29 1: Connection refused from the non-local address 162.142.125.125:1946, as there is no working allowed instance defined for it
2025.12.01 01:26:29 1: Connection refused from the non-local address 162.142.125.125:1948, as there is no working allowed instance defined for it
2025.12.01 01:26:33 1: Connection refused from the non-local address 162.142.125.125:2038, as there is no working allowed instance defined for it
2025.12.01 01:26:36 1: Connection refused from the non-local address 162.142.125.125:2084, as there is no working allowed instance defined for it
2025.12.01 07:38:02 1: Connection refused from the non-local address 167.94.138.116:8824, as there is no working allowed instance defined for it
2025.12.01 07:38:02 1: Connection refused from the non-local address 167.94.138.116:8834, as there is no working allowed instance defined for it
2025.12.01 07:38:03 1: Connection refused from the non-local address 167.94.138.116:11590, as there is no working allowed instance defined for it
2025.12.01 07:38:03 1: Connection refused from the non-local address 167.94.138.116:11606, as there is no working allowed instance defined for it
2025.12.01 07:38:12 1: Connection refused from the non-local address 167.94.138.116:38262, as there is no working allowed instance defined for it
2025.12.01 10:41:44 1: Connection refused from the non-local address 198.235.24.64:61954, as there is no working allowed instance defined for it
2025.12.01 10:41:45 1: Connection refused from the non-local address 198.235.24.64:61970, as there is no working allowed instance defined for it
2025.12.01 15:59:55 1: Connection refused from the non-local address 203.55.131.4:53802, as there is no working allowed instance defined for it
2025.12.01 16:16:10 1: Connection refused from the non-local address 203.55.131.4:38150, as there is no working allowed instance defined for it
2025.12.01 18:36:11 1: Connection refused from the non-local address 45.135.193.9:46070, as there is no working allowed instance defined for it

Ich habe für einen abgeschlossenen Monat mehr als 1000 solche Zeilen gehabt.

"list TYPE=FHEMWEB" ergibt aktuell (ohne global):

Code Auswählen Erweitern

WEB
WEB_127.0.0.1_51772
WEB_127.0.0.1_58006
So ist es ja in Ordnung.

Viele Grüße,
Heiko

[Otto123]

Hallo Heiko,

da ich dein exaktes Setup nur ahnen kann:
mit global bindet FHEM die 8083 an alle Netzwerkschnittstellen: 0.0.0.0:8083 beantwortet aber eigentlich nur Anfragen aus privaten Netzwerken (siehe help FHEMWEB - allowfrom Attribute, dein Log zeigt: es hat genauso gewirkt  )
ohne global bindet FHEM die 8083 an 127.0.0.1:8083
Die Portbindungen kannst Du Dir z.B. mit ss -lntu anschauen.
Insofern sollten jetzt die Logeinträge in FHEM vom 1.12. Geschichte sein.

Dein Proxy wirkt als Sicherheitsschleuse natürlich nicht für "alles" was an die öffentliche IP gebunden ist. Du solltest also darauf achten, dass nur Port 80 und 443 von deinem Proxy an die öffentliche IP gebunden sind. Alles andere sollte nur intern lauschen, ansonsten sind alle Prozesse die öffentlich lauschen potentiell angreifbar.

Gruß Otto

[passibe]

2025.12.06 11:58:40 1: Connection refused from the non-local address 93.174.95.106:59434, as there is no working allowed instance defined for it

Das sind einfach die clientseitigen Ports. Du brauchst ja immer Ports auf beiden Seiten, d.h. FHEM "hört" auf 8083 (bzw. nginx auf 443), aber der Client, der sich verbindet, verbindet sich auch von einem Port aus. Sonst könnte er ja nichts senden. Das sind typischerweise eben diese hohen 40000-50000er Ports.
Dass du auch Traffic von Clients mit niedrigeren Ports siehst liegt daran, dass die die einfach benutzen, weil das irgendwelche bösartigen Bots oder harmlose Scanner (z.B. censys) sind. Schau dir einfach mal an, was das für IPs sind (https://ipinfo.io/<IP>) und dann siehst du das.
Wenn du willst kannst du mit Tools wie crowdsec oder irgendwelchen Blocklisten (dann mit iptables mit ipset) diese Zugriffe ein bisschen blockieren, wirklich sicherer macht das deinen Server aber nicht, sondern hält nur die Logs sauber. Cloudflare proxying davor setzen geht aber auch (dann sehen die halt deinen Traffic).


Zum ursprünglichen Problem mit Authelia:
Erstmal ist diese nginx config (du hast die vermutlich vom wiki?) ein bisschen zu kompliziert, wie wir inzwischen herausgefunden haben. Inzwischen reicht eigentlich folgendes in der location directive:

Code Auswählen Erweitern

# Ensure Websocket proxying works
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";

# Standard reverse proxy headers
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host:$server_port;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

set $upstream 127.0.0.1:8083;
proxy_pass http://$upstream;Wichtig ist auf jeden Fall auch, dass du $upstream verwendest und nicht unmittelbar in proxy_pass die IP/den Hostnamen angibst, weil nginx sonst nicht startet, sollte FHEM einmal nicht verfügbar sein (siehe hier).

Ansonsten scheint es irgendwie so, als wäre Port 8083 nicht blockiert oder nginx macht irgendwas komisches und proxied TCP traffic? Ich bin mir zu 99% sicher, dass FHEM da auch nicht irgendwie X-Forwarded-For auswertet, sondern das Blockieren ausschließlich auf dem TCP-Layer stattfindet. Also – wenn alles richtig konfiguriert ist – kann es eigentlich nicht sein, dass diese IPs in FHEM auftauchen, weil sie gar nicht in der Lage sein sollten, FHEM auf TCP-Ebene zu erreichen.

Ich hoffe du hast auch in deinem FHEMWEB-Device

Code Auswählen Erweitern

allowfrom 127\.0\.0\.1 gesetzt, sonst hast du grade nämlich extrem viel Glück, dass die Standardkonfiguration so schlau ist RFC1918-IPs per Default abzuweisen und dein FHEM grade nicht offen im Netz hängt.
Deshalb solltest du übrigens, auch wenn nginx die Authentifizierung übernimmt, FHEM immer noch mittels eines allowed-Devices (also basicauth) absichern. nginx kann dann einfach beim proxyen den entsprechenden Header an FHEM senden (d.h. der Client kriegt von der im Hintergrund immer noch stattfindenden basicauth nichts mit), aber dann hast du neben der Abweisung von non-RFC1918-Adressen noch eine Verteidigungslinine, sollte – wie jetzt – FHEM doch irgendwie direkt erreichbar sein. Das hilft auch (bedingt) gegen SSRF.
Geht in nginx mit:

Code Auswählen Erweitern

proxy_set_header Authorization "Basic <user:pass in base 64>(<user:pass in base 64> kriegt man mit echo -n 'user:pass' | base64)

Um jetzt die Lösung für dein Problem zu finden, poste bitte mal deine Firewall-Konfiguration und deine nginx-Konfiguration (möglichst vollständig) so wie sie jetzt mit authelia ist.

(Wie du siehst, gibt es vielleicht doch einige Fallstricke hier; deshalb wäre mE auch grundsätzlich zu überdenken, ob du FHEM wirklich komplett ins Netz stellen willst und nicht lieber nginx so konfigurieren willst, dass es nur IPs aus deinem VPN-Subnetz auf FHEM lässt ... Ist dann zwar vielleicht nicht so komfortabel, aber es dürfte ruhigeren Schlaf erlauben. Selektiv irgendwelche Endpoints für Webhooks freigeben (Geofency o.ä.) kann man dann immer noch; die hätten dann aber auch nur die notwendigen Berechtigungen und es wäre eben nicht die volle FHEM-Installation.)

[rudolfkoenig]

Ich bin mir zu 99% sicher, dass FHEM da auch nicht irgendwie X-Forwarded-For auswertet,

Nein tut es nicht, ich tippe darauf, dass der "allowfrom" Code uns beiden geholfen hat.
Heiko, dass er nicht gehackt, und mir, dass ich nicht auf dem Pranger gestellt wurde.