Reverse Proxy über 2 netzwerke

giorgio123
Goto Top
Hallo Zusammen
Ich habe einen Problem und komme alleine nicht weiter... Ich habe einen Revers Proxy im NAT-Bereich der Firewall2. Nun muss dieser Reverseproxy muss eine Auflösung machen für einen Service, der sich im LAN Bereich der Firewall. Die Kommunikation vom Revers Proxy zum Service habe ich das Gefühl, es geht aber der weg zurück nicht. Noch zu erwähnen die Firewall sind 2 verschiedene Netzwerke nicht redundant.

Irgend welchen ideen ?

Besten Dank
Giorgio
screenshot 2022-01-17 084219

Content-Key: 1730841787

Url: https://administrator.de/contentid/1730841787

Ausgedruckt am: 17.05.2022 um 23:05 Uhr

Mitglied: StefanKittel
StefanKittel 17.01.2022 um 09:08:34 Uhr
Goto Top
Moin,

NAT ist doch vermutlich die DMZ.
Also eine Regel in der Firewall 3 konfigurieren, dass der RP auf den Web-Service zugreifen darf.

Stefan
Mitglied: giorgio123
giorgio123 17.01.2022 um 09:35:09 Uhr
Goto Top
Hoi Stefan

Danke für deine rasche Antwort. Von dem NAT/DMZ bereich kann ich den Web-service anpingen. Wenn ich dann aber versuche mit einem Host eintrag auf dem RP zu verbinden um aufs We-service zu kommen bekomme ich keine Antwort.
Mitglied: aqui
aqui 17.01.2022 um 11:06:24 Uhr
Goto Top
Also eine Regel in der Firewall 3 konfigurieren,
WO ist die denn ??
Mitglied: StefanKittel
StefanKittel 17.01.2022 um 11:20:08 Uhr
Goto Top
Zitat von @giorgio123:

Hoi Stefan

Danke für deine rasche Antwort. Von dem NAT/DMZ bereich kann ich den Web-service anpingen. Wenn ich dann aber versuche mit einem Host eintrag auf dem RP zu verbinden um aufs We-service zu kommen bekomme ich keine Antwort.
ICMP ist nicht TCP.
Geht die Anfrage denn wirklich durch FW1 und FW2? Oder wie sind die Verbunden?
Vieleicht mag der Webservice schlicht nicht mit der IP des RP sprechen?
Protokolle in den Firewalls, Einzeltests + Wireshark sind Deine Freunde.

Zitat von @aqui:

Also eine Regel in der Firewall 3 konfigurieren,
WO ist die denn ??
Das war der Wink mit dem Zaunpfahl
Mitglied: emeriks
emeriks 17.01.2022 um 15:22:42 Uhr
Goto Top
Zitat von @aqui:
WO ist die denn ??
In Indien.
Mitglied: glady2000
glady2000 17.01.2022 um 19:06:58 Uhr
Goto Top
Folgende Punkte würde ich überprüfen (wie tlw. auch von anderen bereits geschrieben):
1. Kann der RP den Weberver mit dem entsprechenden Port erreichen? (überzeugen, dass die Firewall(s) korrekt konfiguriert wurden)
2. Falls https: Beim Zugriff vom Client terminiert SSL auf dem RP und der macht ein re-keying zum Backend? Falls ja, steht denn der Trust zwischen RP und Backend?
3. Welches RP-Produkt ist das? Der wird doch bestimmt irgendwas in ein Log schreiben. Diesen mal durchschauen. ggf. kann man auch das Tracelevel erhöhen.
4. Während dem Zugriffstest könnte man auch mal parallel per tcpdump (Linux) oder netsh (Windows) auf dem Webserver mit tracen. dann sieht man ob überhaupt was ankommt und wenn ja, könnte man evtl. irgendwelche Rückschlüsse ziehen.
Mitglied: aqui
aqui 17.01.2022 aktualisiert um 19:30:12 Uhr
Goto Top
Kann der RP den Weberver mit dem entsprechenden Port erreichen?
Genauso sinnvoll ist der Check der Rückroute ob der Webserver den RP erreichen kann und das FW Regelwerk beider FW entsprechend passt.
Mitglied: glady2000
glady2000 17.01.2022 aktualisiert um 19:42:43 Uhr
Goto Top
Zitat von @aqui:

Kann der RP den Weberver mit dem entsprechenden Port erreichen?
Genauso sinnvoll ist der Check der Rückroute ob der Webserver den RP erreichen kann und das FW Regelwerk beider FW entsprechend passt.

Der Webserver baut keine Verbindung rückwärts zum RP auf.
Wenn der RP die Session zum Webserver aufbaut und die Rückantwort-Pakete vom Webserver von der Firewall blockiert werden, liegt ein massiver Fehler auf der Firewall vor -oder natürlich im Routing (z.B. Asymmetrisches Routing, mit dem die Firewalls überhaupt nicht klar kommen). Normalerweise werden für die Rückantwortpakete auf der Firewall dnymisch die Ports aufgemacht, jeweils für die Session. Das nennt man Stateful Packet Inspection.
Der Webserver muss doch gar nicht den RP erreichen. Nur der RP muss den Webserver erreichen können.
Mitglied: aqui
aqui 18.01.2022 aktualisiert um 09:46:04 Uhr
Goto Top
Der Webserver baut keine Verbindung rückwärts zum RP auf.
Aktiv (gesetztes ACK, SYN Bit) sicher nicht aber die Rückrouten Frames müssen ja über ihn laufen. Der Webserver kann ja dem Client niemals direkt antworten, denn dann würden Antwort Frames eine andere Absender IP haben und der Client dann die Verbindung sofort kappen.
TCP Traffic darf ja niemals eine zur ziel verschiedene Antwort Adresse haben. Sowas führt zum sofortigen Abbruch der Session. Folglich geht Prinzip bedingt Hin- und Rücktraffic immer über den RP. Ein Wireshark Trace zeiugt dir das im Detail.
Sprich also Traffic geht vom RP zum Webserver und der Return Traffic wieder via RP zum Client.
Da aber der Traffic RP Web und Web RP über 2 Firewall rennt ist das Regelwerk dieser beiden Firewalls ja essentiell wichtig und muss passen.
Das war damit gemeint diese Regeln sehr genau zu prüfen. Es liegt ja auf der Hand das Teile dieses Traffics irgendwo in einer der Firewalls hängen bleiben !
Wireshark oder tcpdump wäre hier so oder so dein bester Freund und zeigt dir im Handumdrehen wo der Fehler liegt. Man muss es nur mal anwenden...
Mitglied: glady2000
glady2000 18.01.2022 um 11:25:00 Uhr
Goto Top
Zitat von @aqui:
Sprich also Traffic geht vom RP zum Webserver und der Return Traffic wieder via RP zum Client.

Vorsicht, der RP leitet nicht wirklich weiter. Es ist nicht so dass der Client über den RP direkt mit dem Backend kommuziert.
Die Sessions vom Client werden am RP terminiert. Der RP baut neu die Session zum Backend auf und vermittelt in der Mitte.
Deswegen sieht der Client immer nur die IP des RP als destination. Und das Backend sieht immer nur den RP als source.
Mitglied: aqui
aqui 18.01.2022 um 11:56:28 Uhr
Goto Top
Die Sessions vom Client werden am RP terminiert. Der RP baut neu die Session zum Backend auf und vermittelt in der Mitte.
Also leitet er doch weiter bzw. terminiert die original Session ! ;-) face-wink
Das bedeutet dann das auch der Rücktraffic vom Server zum RP rennt wie oben ja geschrieben. Dieser Traffic rennt also ebenfalls durch die 2 Firewalls !
Deswegen sieht der Client immer nur die IP des RP als destination.
Ganz genau...
Für dich relevant ist aber die Kommunikation RP - Web Server und zurück durch die 2 Firewalls !
Hier stimmt de facto etwas mit dem Regelwerk nicht !
Du kannst das ja sehr einfach temporär testen mit einem IP permit von beiden Host IPs RP und Web in den FWs. So schaltest du den Traffic ja quasi auf "Durchzug" ohne Regeln.
Dann sollte es ja in jedem Falle klappen und du hast eine Bestätigung das es dann an falschen FW Regeln scheitert.
Mitglied: glady2000
glady2000 18.01.2022 aktualisiert um 15:09:12 Uhr
Goto Top
Zitat von @aqui:

Die Sessions vom Client werden am RP terminiert. Der RP baut neu die Session zum Backend auf und vermittelt in der Mitte.
Also leitet er doch weiter bzw. terminiert die original Session ! ;-) face-wink
Das bedeutet dann das auch der Rücktraffic vom Server zum RP rennt wie oben ja geschrieben. Dieser Traffic rennt also ebenfalls durch die 2 Firewalls !
Deswegen sieht der Client immer nur die IP des RP als destination.
Ganz genau...
Für dich relevant ist aber die Kommunikation RP - Web Server und zurück durch die 2 Firewalls !
Hier stimmt de facto etwas mit dem Regelwerk nicht !
Du kannst das ja sehr einfach temporär testen mit einem IP permit von beiden Host IPs RP und Web in den FWs. So schaltest du den Traffic ja quasi auf "Durchzug" ohne Regeln.
Dann sollte es ja in jedem Falle klappen und du hast eine Bestätigung das es dann an falschen FW Regeln scheitert.

Der Verfasser hat jetzt viel Input erhalten. Entweder in den Firewalls Logs (irgendwelche denys) oder im RP Log müsste sich ja irgendwas Verwertbares finden lassen. Vielleicht haben wir Glück und er gibt uns noch Feedback :-) face-smile
Mitglied: aqui
aqui 18.01.2022 um 16:49:38 Uhr
Goto Top
Kein Feedback von ihm ist ja auch ein Feedback ! :-( face-sad
Mitglied: aqui
aqui 03.02.2022 um 10:26:04 Uhr
Goto Top
Wenn's das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu markieren !!
https://administrator.de/faq/32