Incoming NAT - unerwünscht

[Emma2]

Hallo.

Meine opnSense macht für hereinkommende Anfragen NAT - und das möchte ich nicht.
Ich habe nichts dergleichen eingestellt und weiß daher auch nicht, wo ich das abschalten soll.

Mein Szenario: Ich leite hereinkommende Anfragen per HAProxy auf meinen Webserver, und dort wird - nach Zustimmung zu einer entsprechenden Datenschutzerklärung - die IP des Anfragers protokolliert. (NB: Es geht um Kundendownloads von unserem Server.)

Seit ich die opnSense in Betrieb genommen habe, steht im Protokoll jedoch nicht mehr die externe Anfrager-IP, sondern die interne IP unserer opnSense.

Mache ich einen Denkfehler, oder habe ich nur eine falsche Einstellung?

[Alphakilo]

Benutzt du das HAProxy Plugin?

Seit ich die opnSense in Betrieb genommen habe, steht im Protokoll jedoch nicht mehr die externe Anfrager-IP, sondern die interne IP unserer opnSense.

Gesetzt dem Fall das du das HAProxy Plugin verwendest und du das Protokoll des Zielservers meinst ist das "working as intended".
HAProxy nimmt den Request aus dem WAN an, und stellt dann einen neuen, eigenen Request an den Zielserver. Und dieser wird vom Zielserver geloggt.

Du könntest also entweder vom HAProxy einen HTTP-Header (X-Forwarded-For, X-Client-IP, ...) setzen und diesem am Zielserver in's Logging einbinden, oder du machst statt Reverse Proxying wieder ganz traditionelles Port Forwarding.

[Emma2]

Hallo, AK.

du machst statt Reverse Proxying wieder ganz traditionelles Port Forwarding.

Nö, das geht nicht, denn ich muss hereinkommende Anfragen gezielt auf verschiedene Server verteilen.

Du könntest also entweder vom HAProxy einen HTTP-Header (X-Forwarded-For, X-Client-IP, ...) setzen und diesem am Zielserver in's Logging einbinden

Hättest Du dazu einen Tipp für mich? Auf Anhieb finde ich das wegen meiner mangelnden Kenntnisse nicht.

[Alphakilo]

Verstehe.

Ich kann man ein bisschen suchen, ist aber schwierig für mich das zu testen.
Was für Webserver sind hinter deinem HAProxy?

[Emma2]

Ich kann man ein bisschen suchen, ist aber schwierig für mich das zu testen.

Danke für das Angebot. Interessieren würde mich das schon, aber mache Dir nicht zu viel Stress:
Da mein Aufruf den Nutzernamen mit überträgt, brauche ich die IP nicht unbedingt.
(Ist nur manchmal interessant zu sehen, welche Kunden aus welchen LÄNDERN wann die Updates ziehen ;-).

Was für Webserver sind hinter deinem HAProxy?

In diesem Fall sind es Microsoft'sche IISe.

Hintergrund:
Unser Update-Client (der auf dem Kundenrecher läuft) ruft eine URL auf unserer Webseite auf und hängt die Authentifizierungsinfo als Parameter an. Bisher gab es nur "eine Lizenz für alle", so dass wir nur über die IP sehen konnten, woher ein Aufruf kam, Mit unserem neuen Lizenzsystem gibt es jedoch individuelle Downloadkonten, so dass wir wie gesagt die IP nicht mehr unbedingt brauchen.

Warum ich den HAProxy überhaupt brauche? Wir haben unsere Webseiten extern auf SSL umgestellt, aber über den selben Port 443 kommen eben auch die Anfragen für unseren Applikationsserver/RDP - und beide nutzen natürlich unterschiedliche Zertifikate. (NB: Auf dem TMG war das gar nicht zu managen, ein Grund mehr auf die opnSense umgestiegen zu sein ...)

[Alphakilo]

Da mein Aufruf den Nutzernamen mit überträgt, brauche ich die IP nicht unbedingt.
(Ist nur manchmal interessant zu sehen, welche Kunden aus welchen LÄNDERN wann die Updates ziehen ;-).

Wo wertet ihr die Daten denn aus? Direkt am Webserver (Access-Log) oder in eurer Web-Applikation?
Der HAProxy müsste ein eigenes Access-Log führen. Welches übrigens wenig Rücksicht auf etwaige opt-ins nimmt.

In diesem Fall sind es Microsoft'sche IISe.

Mein Beileid. Zugegeben: der IIS soll sich gemacht haben, kann ich aber weder bestätigen noch dementieren 

Für das Logging habe ich folgendes gefunden:
http://www.loadbalancer.org/blog/iis-and-x-forwarded-for-header/

Bisher gab es nur "eine Lizenz für alle", so dass wir nur über die IP sehen konnten, woher ein Aufruf kam

Die "legacy" Applikation könnte eben besagten "X-Forwarded-For" Header als ACL auswerten.
Ihr solltet dann aber darauf achten das der HAProxy den Header *immer* setzt, auch dann wenn er aus dem WAN schon gesetzt ist.. Sonst könnte man den als findiger Client einfach selbst schreiben.

Also was tun?

Im jeweiligen Backend muss die Option "option forwardfor"¹ gesetzt sein. Im Plugin müsste man das unter "Real Server" -> "Option Passthrough" konfigurieren können.

Im Frontend (Public Services) gibt es eine Checkbox ("X-Forwarded-For").

Aber wie gesagt. Das ist ungetestet. Ich verwende derzeit noch meine eigene Box als Reverse Proxy.

Ich würde dir, ganz unabhängig von dem Rest, mal empfehlen den Qualys SSL/TLS Server Test drüber laufen zu lassen:
https://www.ssllabs.com/ssltest/

¹: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#option%20forwardfor

[Emma2]

Wo wertet ihr die Daten denn aus? Direkt am Webserver (Access-Log) oder in eurer Web-Applikation?

In unserer Applikation: wir schreiben das in unsere eigene Datenbank.

In diesem Fall sind es Microsoft'sche IISe.

Mein Beileid. Zugegeben: der IIS soll sich gemacht haben, kann ich aber weder bestätigen noch dementieren 

Na ja, wir kommen halt aus der Microsoft-Welt... und es war noch schlimmer: bis vor drei Wochen hatten wir den (glücklicherweise abgekündigten) TMG im Einsatz - ein riesiges, sperriges Monstrum, das sich ganz tief in der Domäne verankert... und dann nicht einmal auf die eigenen DNS-Einträge zugreifen kann... na ja, ist zum Glück auch für uns Geschichte. Und ja, wir überlegen, noch ein paar andere unserer Server auf Linux/Unix-Tools umzustellen. Wenn die alle so einfach zu bändigen sind wie die opnSense, dann machen wir das gerne.

(Den Rest Deiner interessanten Tipps muss ich mal in Ruhe lesen -  danke auf alle Fälle!)

[NicholasRush]

Wo wertet ihr die Daten denn aus? Direkt am Webserver (Access-Log) oder in eurer Web-Applikation?

In unserer Applikation: wir schreiben das in unsere eigene Datenbank.

In diesem Fall sind es Microsoft'sche IISe.

Mein Beileid. Zugegeben: der IIS soll sich gemacht haben, kann ich aber weder bestätigen noch dementieren 

Na ja, wir kommen halt aus der Microsoft-Welt... und es war noch schlimmer: bis vor drei Wochen hatten wir den (glücklicherweise abgekündigten) TMG im Einsatz - ein riesiges, sperriges Monstrum, das sich ganz tief in der Domäne verankert... und dann nicht einmal auf die eigenen DNS-Einträge zugreifen kann... na ja, ist zum Glück auch für uns Geschichte. Und ja, wir überlegen, noch ein paar andere unserer Server auf Linux/Unix-Tools umzustellen. Wenn die alle so einfach zu bändigen sind wie die opnSense, dann machen wir das gerne.

(Den Rest Deiner interessanten Tipps muss ich mal in Ruhe lesen -  danke auf alle Fälle!)

Ich habe mich immer gefragt wer denn Freiwillig den TMG von Microsoft einsetzt, da gab es damals doch schon so viele und bessere Alternativen.

[Emma2]

Ich habe mich immer gefragt wer denn Freiwillig den TMG von Microsoft einsetzt, da gab es damals doch schon so viele und bessere Alternativen.

... und warum sagst Du mir das erst jetzt?

[JeGr]

> Ich habe mich immer gefragt wer denn Freiwillig den TMG von Microsoft einsetzt, da gab es damals doch schon so viele und bessere Alternativen.

zB die ganzen Firmen, die u.a. sowas "kleines" wie den SBS oder Nachfolger einsetz(t)en und sich dann mit dem "alles aus einer Hand" Konzept haben rumkriegen lassen. Was TMG alles für gruselige Sachen macht und setzt, sehen die dann, wenn wir Stück für Stück ihren TMG ablösen und in *sense überführen und hinterher dann ggf. in 5-10 Regeln das haben, was vorher Bildschirmseiten TMG war und keiner verstanden hat, weil der Kram mies dargestellt wird.

Gruseliger Mist

[Emma2]

Rückmeldung:

Vielen Dank, vor allem an AK, für die Tips und Unterstützung.
Wir haben es jetzt so gemacht (X-Forwarded-For), da uns allerdings die Syntax über die GUI nicht ganz klar war, haben wie es nach einem anderen Thread eingetragen:https://forum.opnsense.org/index.php?topic=7596.0

Funktioniert auf alle Fälle wie gewünscht