Original IP bei CDN Portmapper Forwarding herausfinden

Mic2025 · 4. August 2025 um 07:59

Guten Morgen zusammen,

ich habe eine Frage zum CDN Portmapper mit CDN Reverse Proxy. Ich hatte ja schon erzählt, dass ich IPV64.net dafür nutze, um meine NextCloud übers Internet erreichbar zu machen. Für IPv6 geht das über den direkten Weg via IPV64.net Domain. Für IPv4 nutze ich den IPV64.net CDN Portmapper.

Nun habe ich in meinen Docker Container den Caddy Reverse Proxy mit CrowdSec Schutz eingebaut, um meine NextCloud vor diversen Angriffsszenarien zu schützen. Dabei wird einer problematischen IP-Adresse der Zugriff gesperrt. Für den direkten Weg für IPv6 funktioniert das prima. Geht man über den Weg mit dem CDN Portmapper, bekommt man aber immer eine Art Fake-IP-Adresse als Zugreifer angezeigt. Es scheint, als ob die IP-Adresse des Ursprungs einer Anfrage nicht durch den CDN Dienst an meinen Caddy übertragen wird. Dafür müsste es einen Eintrag wie „X-Forwarded-For“ geben, den ich per CrowdSec auswerten kann. Der kommt aber bei mir nicht an.

Kann das sein oder mache ich hier etwas falsch? Wenn das fehlt, könntest du das evtl. noch ergänzen, @Dennis_Admin?

Vielen Dank für eure Unterstützung.

Grüße Mic.

Benjamin · 4. August 2025 um 11:08

Kannst du verifizieren ob das ohne cdn funktioniert hat? Ich habe das nie hinbekommen. Docker ist ein ziemlicher Geheimniskrämer. Nat…

Mic2025 · 4. August 2025 um 11:43

Hallo @Benjamin ,

ich habe zwar ziemlich lange rumgefummelt aber der direkte Weg funktioniert jetzt einwandfrei. Ich nutze dafür das von CrowdSec mitgelieferte Standard-Szenario für NextCloud. Das muss man mit einem Befehl im Docker installieren und dann im Caddyfile sauber konfigurieren.

Wenn ich ca. 10-mal recht schnell nacheinander die falschen Login-Daten eintippe, bekomme ich irgendwann beim Reload der Seite ein “403 Forbidden”. (Achtung: Parallel blockt auch der in NextCloud eingebaute Schutz deine IP. Kann/muss man über einen Command Line Befehl wieder ent-blocken.) Du musst allerdings den Cache deines Browsers löschen. Wenn die Seite noch darin ist, siehst du sie auch im geblockten Zustand noch und das Blocking scheint nicht funktioniert zu haben.

Hinweis: Ich habe alles (Nextcloud-DB, NextCloud-App, Caddy und CrowdSec) in einen gemeinsamen aber eigenen MacVLAN mit eigenem Gateway zum Internet laufen.

Für den Umweg über den CDN-Portmapper greift das Standard-Szenario aber leider nicht und man muss sich einen eignen Caddy Log Parser und ein eigenes Szenario bauen. Caddy wertet den Header bei einer Anfrage aus und schreibt dessen Inhalt in eine neue YAML-Logzeile in assess.log. Leider finde ich darin nur die (nennen wir sie mal) Fake-IP vom CDN aber nicht die IP der eigentliche Quelle des Aufrufs. Daher kann man kein Szenario bauen, die diese dann blockiert.

Danke und Grüß
Mic.

Benjamin · 4. August 2025 um 13:52

Das könnte durch das macvlan funktionieren? Keine Ahnung. Ich habe leider den Effekt das nextcloud nur die IP vom Reverse Proxy sieht und blockt. Ist dann zwar auch zu, aber für alle. Ich denke du hast diesen Effekt jetzt mit dem externen Proxy eben.

Mic2025 · 5. August 2025 um 07:42

Hallo @Benjamin,

ja, wenn du komplett über einen externen Proxy gehst, passiert genau das. So ist es jetzt bei meinem IPv4-Zugang auch. Für den Zugang über IPv6 habe ich IPV64.net CDN aber nicht aktiv. Da geht es direkt über der Domain und dann funktioniert es so, wie es soll.

Ich nutze intern den Caddy als Reverse Proxy und genau in dessen Route klinkt sich CrowdSec ein. (Daher muss man sich ja auch so einen gepatchten Container selbst bauen und kann nicht das Standard-Image für Caddy verwenden.)

Ich habe aber im Netz gelesen, dass Proxys über das Header-Feld „X-Forwarded-For“ die IP-Adresse des originalen „Zugreifers“ weiterleiten können. Wenn so ein Feld vorhanden ist, nutzt CrowdSec dieses als Ersatz für das Header Feld „source_ip“. (Das kann man in der Datei acquis.yaml konfigurieren.) Dieses Feature bringt CrowdSec nativ mit. Man muss angeblich nicht mal einen Parser dafür schreiben.

Von daher hoffe ich, dass @Dennis_Admin freundlicherweise dieses Header Feld „X-Forwarded-For“ noch in den IPV64.net CDN einbaut. Es ist ja noch im Beta- als Entwicklungsstadium.

Wenn es das Feld gäbe, hätte das für den Nutzer den Nachteil, dass er nicht mehr anonym ist, hätte aber für uns den Vorteil, dass wir Angriffe gezielt abwehren können.

Schauen wir mal…

Grüße
Mic.

Dennis_Admin · 5. August 2025 um 08:51

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Using this setting, Nginx adds the $remote_addr to the end of the existing X-Forwarded-For header, preserving the entire chain of IP addresses through proxies.

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Steht bei jeder Domain drin..

Mic2025 · 5. August 2025 um 12:55

Hallo Dennis,

danke für deine Input. Irgendwie hatte ich mir gedacht, dass du diese Info schon bereitstellst. Ich habe beim Caddy Reverse Proxy nachgelesen, dass man die statische IP des externen Proxy (also vom IPV64.net CDN Proxy) als „trusted IP“ eintragen soll, dann nimmt er die erste „unbekannte IP“ als eigentliche Quelle der Anfrage und trägt sie als „client ip“ ein. Ich meine aber gesehen zu haben, dass sich die IP des CDN Proxy, wie sie von meinem Caddy erkannt wird, ändert. Kann das sein oder welche IP (IPv4 und IPv6) des IPV64.net CDN Proxy kann ich als „trusted IP“ eintragen? Hast du da eine statische IP?

{
servers {
trusted_proxies static 12.34.56.0/24 1200:ab00::/32
}
}

Ich nehme an, die Reihenfolge der übertragenen IP-Adressen „left to right“ ist für IPV64.net die Richtige, oder?

Quelle: Global options (Caddyfile) — Caddy Documentation

Danke und Grüße
Mic.

Mic2025 · 5. August 2025 um 19:31

Hallo zusammen,

also ich habe mich heute Abend nochmal recht intensiv mit meinem Caddy Reverse Proxy beschäftigt. Er kann X-Forwarded-For tatsächlich auflösen und die (Quell-)IP-Adresse entsprechend mappen.

Wenn ich das richtig verstehe, beinhaltet X-Forwarded-For typischerweise eine Liste an IP-Adressen, über die eine Anfrage bis zum Zielserver weitergeleitet wird. Dabei kann das auch eine Mischung aus IPv4 und IPv6 sein. So etwas müsste demzufolge bei einem Routing über den IPV64.net CDN Portmapper (IPv4 zu IPv6) sein.

Hier einfach mal ein Beispiel:
X-Forwarded-For: 203.0.113.195, 2001:db8:85a3:8d3:1319:8a2e:370:7348, 198.51.100.178

Mit etwas Kopfstand habe ich mir den Inhalt von X-Forwarded-For anzeigen lassen, da Caddy dieses Header Feld standardmäßig nur verarbeitet aber nicht weitergibt oder in den Log schreibt. Ich sah dann, dass in X-Forwarded-For, wenn ich meine Webseite über das CDN-Port vom IPV64.net Portmapper öffne, nur eine IPv6-Adresse drinsteht. Das muss die IPv6 des CDN Portmappers (bzw. dessen Server) selbst sein. Alles „was davor passiert ist“, kommt bei mir nicht an. Da hilft dann leider auch trusted_proxies im Caddyfile nix.

Ich sehe nur diese eine IP-Adresse: 2a01:4f8:1c0c:5669::1
Und manchmal kommt stattdessen auch: 2a01:4f8:192:1326::b00b:cafe

Und da komme ich nun nicht weiter und brauche jemand, der sich besser damit auskennt als ich. Vielleicht hat @Dennis_Admin hier ein paar hilfreiche Inputs für mich.

Danke und Grüße
Mic.

Dennis_Admin · 6. August 2025 um 07:11

Ich habs jetzt mal in “proxy_set_header X-Forwarded-For $http_x_forwarded_for;” geändert.

Die Server IPs sind doch öffentlich. Für mehr hab ich gerade keine Zeit, sorry.

Mic2025 · 6. August 2025 um 09:54

Hi @Dennis_Admin,

super und vielen Dank für deine Megaschnelle Hilfe. Ich konnte es eben nur kurz am Handy über Mobile Daten testen. Nach deiner Änderung trägt Caddy jetzt nicht mehr die IP deines CDN-Servers, sondern die IP meines Handys als “source_ip” in den Log ein. (So soll es sein.) In der Theorie müsste das jetzt heißen, dass er die IP des CDN Server als “trusted_ip” aus “X-Forwarded-For” überspringt und dann gleich meine Handy-IP sieht. Diese müsste dann CrowdSec gezielt blocke können. Das muss ich mir aber die Tage mal daheim in Ruhe ansehen. Wenn sich dabei mein Test bestätigt, dann habe ich jetzt von IPV64.net CDN alles, was ich brauche.

Ja, die Serverliste habe ich gefunden. Ich denke, ich werde alle Server als “trusted_ip” eintragen und hoffe, dass du mich nie angreifen wirst (Scherz am Rande).

Link: IPv64 CDN Service • Reverse Proxy & Portmapper

Ich melde mich, wenn ich mehr getestet habe. (DaumenDrücken)

Danke und Grüße
Mic.

Benjamin · 6. August 2025 um 15:20

Ich möchte kurz danke sagen, jetzt weiß ich endlich wofür die trusted proxies sind, und dass ich sie vielleicht Mal ordentlich einstellen sollte

Dennis_Admin · 6. August 2025 um 20:32

Immer geil irgendwie helfen zu können.

Mic2025 · 8. August 2025 um 05:57

Guten Morgen @Benjamin,

sehr gern. Ich habe auch eine Weile gebraucht, bis ich das durchstiegen habe, zumal jedes Programm die Sache anders zu behandeln scheint.

Guten Morgen @Dennis_Admin,

auch dir vielen Dank für deinen schnellen Einsatz. Ich befürchte aber, ich benötige deine Hilfe nochmal. Nachdem es vorgestern reproduzierbar funktioniert hat, geht es seit gestern gar nicht mehr. Mein Caddy Reverse Proxy und auch meine NextCloud „sehen“ die IP-Adresse des IPV64.net CDN-Servers aber keine IP-Adresse „dahinter“. Hast du nochmal was geändert?

Falls du mal fünf Minuten Zeit hast, könntest du bitte mal testen, welche IP-Adressen bei dir alles im Header X-Forwarded-For zu sehen sind? (Man muss die Webseite mit CDN-Port über einen anderen Internetanschluss laden, als man z.B. die NextCloud gehostet hat, sonst kommt es zu einem „Rebound-Effekt“, die IP-Route umgeht den CDN-Proxy, man sieht die echte Quell-IP-Adresse als „source_ip“ und man denkt, es funktioniert. Tut es aber leider nicht.)

Eigentlich müsste das Ding ja im lokalen Caddy Reverse Proxy z.B. so aussehen:
X-Forwarded-For: 2021:dfe::2 2a01:4f8:1c0c:5669::1
X-Forwarded-For: (Quell-IP) (CDN-IP)

Und in der NextCloud (die „nach“ dem Caddy kommt) dann z.B. so:
X-Forwarded-For: 2021:dfe::2 2a01:4f8:1c0c:5669::1 192.123.123.123
X-Forwarded-For: (Quell-IP) (CDN-IP) (lokale Caddy-IP)

Und dann habe ich seit gestern das merkwürdige Phänomen, dass ich im Browser am PC meine Domain-Adresse mit CDN-Port nicht mehr öffnen kann. Wenn ich diese eingebe, switcht er sofort auf die normale Domain-Adresse ohne CDN-Port um. Ich habe das mit mehreren Browsern jeweils unter Windows und unter Linux ausprobiert. Lediglich der Browser auf meinem Android-Smartphone öffnet die Adresse mit CDN-Port noch.

Beispiel:
Ich gebe ein: https://mein-domain.ipv64.de:56123
Es öffnet sich: https://mein-domain.ipv64.de

Danke und Grüße
Mic.

Mic2025 · 8. August 2025 um 19:42

Hallo,

nachdem heute zwischendurch mal gar nichts funktioniert hat, bin ich jetzt wieder soweit, dass Caddy Reverse Proxy als “client_ip” und “remote_ip” die echte IP des Geräts anzeigt, was die Webseite über den CDN-Port aufruft.

Nachfolgend NextCloud sieht aber weiterhin nur die lokale IP meines Caddy und die IP des CDN-Servers von IPV64.net. Entweder gibt Caddy die IPs nicht richtig weiter oder NextCloud nimmt sie nicht an.

Weiß jemand, wie man Caddyfile und config.php (von NextCloud) dafür richtig konfiguriert?

Ach und @Dennis_Admin, verrate uns doch bitte mal, was es bedeutet, wenn beim DynDNS-Update eine Response mit einer IPv6 mit x:x:x:dead:beef:x zurück kommt oder wenn beim CDN-Server die IPv6 2a01:4f8:192:1326::b00b:cafe als “client_ip” o.ä. zurück kommt?

Hier komme ich leider erst mal nicht weiter…

Grüße
Mic.

Mic2025 · 10. August 2025 um 11:23

Hallo Leute,

ich drehe mich hier im Kreis und komme nun doch wieder beim IPV64.net CDN-Server an. Ich denke, ich habe jetzt meine Route sauber aufgebaut.

Quell-Gerät –> CDN-Server –> Caddy –> Apache (in NextCloud) –> NextCloud

Ich habe allen Zwischenschritten in meinem System gesagt, sie sollen den Servern von IPV64.net vertrauen und X-Forwarded-For so weitergeben, dass der nächste Schritt alles sieht. Das funktioniert nun… aber leider nur so halb.

Das komische ist, dass bei „harmolsen“ Anfragen (Laden des Hintergrundbildes der NextCloud) die richtige IP in X-Forwarded-For angezeigt wird. Bei Anfragen, wie einem Login-Request, wird aber die IP des IPV64.net CDN-Servers als X-Forwarded-For angezeigt.

Diesen Unterschied sehe ich im Log von Caddy aber auch im Log der NextCloud (Apache, als auch nextcloud.log).

Quelle	Log-Eintrag	Angezeigte IO
Bilder, Icons	/favicon.ico	IP des Handys
Login, POST	/login	IP des CDN-Server

Wenn ich mir auf der Kommandozeile einen Fake-Header X-Forwarded-For baue, dann kommt der sogar durch:
curl -I ``https://meine-domain.ipv64.net:55123`` -H „X-Forwarded-For: 1.2.3.4“
Ergebnis im Caddy-Log:
X-Forwarded-For":[„1.2.3.4, 2a01:4f8:1c0c:5669::1“]

Wenn ich über die Webseite einen Login-Versuch mache, sehe ich im Caddy-Log:
X-Forwarded-For":[„2a01:4f8:1c0c:5669::1“]

Es scheint also so zu sein, dass der X-Forwarded-For Header vom CDN-Server nur bei “harmlosen” Requests kommt. Das hat vielleicht etwas mit der TSL-Verschlüsselung zutun.

@Dennis_Admin, kann es sein, dass du verschlüsselte Anfragen über eine andere Route leitest oder anderes behandelst, sodass deren Header im CDN-Server separat konfiguriert werden müssen?

Wenn noch jemand gute Ideen hat, bin ich offen dafür.

Viele Grüße
Mic.

Mic2025 · 10. August 2025 um 11:31

Off-Topic aber jetzt muss ich mich mal über die Konkurrenz auskotzen. Ich habe auch eine Anfrage im offiziellen NextCloud-Forum gestellt, weil es ja auch daran liegen könnte. Die haben jetzt meine Anfrage einfach geschlossen (sodass ich nichts mehr drauf schreiben kann) und meinten sinngemäß: “Na dann liegt’s wohl am CDN, wenn bei Caddy nichts ankommt.” Frechheit!

Dennis_Admin · 10. August 2025 um 11:54

Ganz ehrlich, ich hab keine Idee wieso dir an unterschiedlichen Stellen die diversen IPs angezeigt bekommst.

Im Hintergrund läuft nix anderes als ein NGINX der x forwarded for macht. Ich müsste mich jetzt selber ein Szenario bauen um das zu testen..

The_eagle · 10. August 2025 um 14:31

man kann weiterhin bei besagter Konkurrenz auf deinen Beitrag antworten. Wenn du dazu nichts mehr schreiben kannst dann weil es bei dieser Konkurrenz eine zahlenmäßige Begrenzung der Beiträge neuer Mitglieder gibt.

Zudem kann ich sehen (und das ist extrem ungewöhnlich) dass dein Beitrag für ca. eine Stunde „unsichtbar“ gesetzt wurde. Die Gründe dafür kann ich nicht sehen.

Mic2025 · 10. August 2025 um 15:23

Hallo @Dennis_Admin,

du sagst, da läuft ein NGINX, der X-Forwarded-For macht. Was genau heißt das? Erzeugt er einen eignen, neuen X-Forwarded-For Header oder reicht er nur einen existierenden Header weiter?

Eine Option wäre, dass der CDN-Server den X-Forwarded-For Header nur weiterreicht, wenn er von der “Stelle davor” schon kommt. Wenn die “Stelle davor” aber z.B. mein Handy ist, ist das die Quelle der Anfrage. Dort gibt es also noch kein X-Forwarded-For. In dem Fall müsste der CDN-Server einen X-Forwared-For Header erst erstellen, in dem an Position 1 die IP meines Handys drin steht. Mein Caddy nimmt diesen Header dann an, ergänzt die IP des CDN-Servers und reicht ihn an Apache weiter. Der nimmt ihn dann wieder an und ergänzt die IP des Caddy. (So verstehe ich das System zumindest.)

Das würde vielleicht erklären, warum es mit meinem CURL-Request klappt. Da schicke ich ja schon einen X-Forwarded-For Header mit, den der CDN-Server nutzen und erweitern kann.

Warum es bei “normalen” Requests scheinbar funktioniert und bei Login-Requests mit TSL-Handshake nicht funktioniert, dafür habe ich auch noch keine zufriedenstellende Erklärung. Vielleicht bypasst NextCloud bei normalen Anfragen den CDN-Server sogar und es geht deswegen. Nur die sicherheitsrelevanten Anfragen laufen über den “offiziellen Weg”.

Anfrage	Methode	Status	X-Forwarded-For IP
/login	GET	200	CDN-IP
/apple-trace	GET	404	echte Quell-IP
/favicon.ico	GET	404	echte Quell-IP

Alles irgendwie sehr merkwürdig…

Grüße
Mic.

PS.: Ja, @The_eagle, die haben mich im NextCloud-Forum wieder freigeschaltet, allerdings kann ich nicht mehr drauf antworten. Auch sehr merkwürdig. Anyhow… Ich glaube, die können mir tatsächlich nicht wirklich helfen - und wollen es auch nicht.

Mic2025 · 10. August 2025 um 15:35

Hallo nochmal @Dennis_Admin,

ich kenne mich jetzt mit NGINX nicht so gut aus aber ich habe mal bissl im Internet rumgeschaut und folgendes gebastelt. Vielleicht kann so eine Konfiguration auf dem CDN-Server funktionieren?

# Mapping: Wenn kein Header vorhanden, setze ihn auf $remote_addr
map $http_x_forwarded_for $xff_header {
    ""      $remote_addr;
    default "$http_x_forwarded_for, $remote_addr";
}

server {
    listen 443;  # oder 80 ohne TLS

    location / {
        proxy_set_header X-Forwarded-For $xff_header;

        # Optional: Weiterleiten anderer Header
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Idee dahinter:

$http_x_forwarded_for prüft, ob ein Header vom Client kommt
Wenn leer, wird $xff_header auf $remote_addr gesetzt
Wenn nicht leer, wird die IP angehängt
proxy_set_header setzt den neuen oder erweiterten Header

Grüße
Mic.