14
Reverse Proxy über 2 netzwerke
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1730841787
Url: https://administrator.de/contentid/1730841787
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
14 Kommentare
Neuester Kommentar
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
NAT ist doch vermutlich die DMZ.
Also eine Regel in der Firewall 3 konfigurieren, dass der RP auf den Web-Service zugreifen darf.
Stefan
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.
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.
Also eine Regel in der Firewall 3 konfigurieren,
WO ist die denn ??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.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.
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.
Das war der Wink mit dem Zaunpfahl
1
In Indien.
1
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.
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.
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.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.
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...
Zitat von @aqui:
Sprich also Traffic geht vom RP zum Webserver und der Return Traffic wieder via RP zum Client.
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.
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 ! 
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.
Zitat von @aqui:
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 !
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.
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 ! 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
Kein Feedback von ihm ist ja auch ein Feedback ! 
Wenn's das denn nun war bitte nicht vergessen deinen Thread dann auch als erledigt zu markieren !!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
