5
Apache Webserver hinter ASA Firewall nicht zu erreichen
Hallo Zusammen,
folgendes Problem, mein Arbeitskollege hat einen Apache Webserver auf seinem Rechner laufen, auf welchem Banken zugreifen sollen um irgendwelche Daten zu hinterlegen. Hier mal eben ein Ausschnitt der Netzstruktur um es sich besser vorstellen zu können.
Hausinterne IP Adresse des Kollegen: 192.168.32.147, heißt Intern kann ich über diese Adresse + Port auf den Webserver zugreifen -> https://192.168.32.147:443 oder https://192.168.32.147/webdav, funktioniert auch.
IP des Intranators, also des zugriffes übers internet, erfinde ich jetzt frei, ist 1.2.3.4. Dieser Rechner hat die Einstellung, das wenn jemand mit den Port 443 kommt, also https://1.2.3.4:443 oder https://1.2.3.4/webdav, er direkt an den Rechner des Kollegen weitergeleitet wird (Portforwarding), also an die 192.168.32.147. Das klappt auch, solange ich im Hausnetz bin, heißt mein Rechner hat die interne IP Adresse 192.168.32.153 und ich gebe im Internet Explorer https://192.168.32.147/webdav oder aber auch https://1.2.3.4/webdav (was ja die öffentliche IP des Intranator Rechners ist und ich nach meinem Verständnis aus dem Haus raus und wieder über den "offiziellen Weg" rein komme) ein, so komme ich auf die erstellte Seite des Kollegen.
Also nochmal, ich gebe im Browser die öffentlich IP des Intranators ein mit entsprechendem Port und werde auf den Rechner des Kollegen weitergeleitet und bekomme die Seite zu sehen.
Versuche ich das selbe von daheim aus oder egal wo, so scheint es nicht zu funktionieren. Ich denke man muss nicht mehr groß was umstellen damit es klappt, doch das Problem finde ich nicht.
Im ASA Log erhalte ich folgende Meldungen wenn ich vom Laptop aus auf den Webserver zugreifen will (nicht erfolgreich):
Nov 03 2015 11:19:11 302013 [hier stand die IP meines Laptops] 51736 192.168.32.147 443 Built inbound TCP connection 9610726 for DMZ:[hier stand die IP meines Laptops]/51736 ([hier stand die IP meines Laptops]/51736) to inside:192.168.32.147/443 (192.168.32.147/443)
kurz darauf folgt diese Meldung:
Nov 03 2015 11:19:20 302014 [hier stand die IP meines Laptops] 51734 192.168.32.147 443 Teardown TCP connection 9610559 for DMZ:[hier stand die IP meines Laptops]/51734 to inside:192.168.32.147/443 duration 0:00:30 bytes 0 SYN Timeout
Folgende Einstellungen habe ich dies bezüglich auf der ASA bereits vorgenommen:
Bei den Access Rules im DMZ (sozusagen outside): Source "any", Destination "Rechner des Kollegen", Service "https", Action "Permit"
Bei den Access Rules inside: Source "Rechner des Kollegen", Destination "any4", Service "ip", Action "Permit"
Bei den NAT Rules: Source Intf "inside", Dest Intf "outside" (nicht DMZ, liegt es daran? DMZ liegt zwischen Out und inside), Source "Rechner des Kollegen", Destination "any", Service "any", Source "outside".
Falls noch Informationen fehlen einfach melden.
Vielen lieben dank im vorraus!!!
Gruß
Burak
___________________________
Bild zum Kommentar
folgendes Problem, mein Arbeitskollege hat einen Apache Webserver auf seinem Rechner laufen, auf welchem Banken zugreifen sollen um irgendwelche Daten zu hinterlegen. Hier mal eben ein Ausschnitt der Netzstruktur um es sich besser vorstellen zu können.
Hausinterne IP Adresse des Kollegen: 192.168.32.147, heißt Intern kann ich über diese Adresse + Port auf den Webserver zugreifen -> https://192.168.32.147:443 oder https://192.168.32.147/webdav, funktioniert auch.
IP des Intranators, also des zugriffes übers internet, erfinde ich jetzt frei, ist 1.2.3.4. Dieser Rechner hat die Einstellung, das wenn jemand mit den Port 443 kommt, also https://1.2.3.4:443 oder https://1.2.3.4/webdav, er direkt an den Rechner des Kollegen weitergeleitet wird (Portforwarding), also an die 192.168.32.147. Das klappt auch, solange ich im Hausnetz bin, heißt mein Rechner hat die interne IP Adresse 192.168.32.153 und ich gebe im Internet Explorer https://192.168.32.147/webdav oder aber auch https://1.2.3.4/webdav (was ja die öffentliche IP des Intranator Rechners ist und ich nach meinem Verständnis aus dem Haus raus und wieder über den "offiziellen Weg" rein komme) ein, so komme ich auf die erstellte Seite des Kollegen.
Also nochmal, ich gebe im Browser die öffentlich IP des Intranators ein mit entsprechendem Port und werde auf den Rechner des Kollegen weitergeleitet und bekomme die Seite zu sehen.
Versuche ich das selbe von daheim aus oder egal wo, so scheint es nicht zu funktionieren. Ich denke man muss nicht mehr groß was umstellen damit es klappt, doch das Problem finde ich nicht.
Im ASA Log erhalte ich folgende Meldungen wenn ich vom Laptop aus auf den Webserver zugreifen will (nicht erfolgreich):
Nov 03 2015 11:19:11 302013 [hier stand die IP meines Laptops] 51736 192.168.32.147 443 Built inbound TCP connection 9610726 for DMZ:[hier stand die IP meines Laptops]/51736 ([hier stand die IP meines Laptops]/51736) to inside:192.168.32.147/443 (192.168.32.147/443)
kurz darauf folgt diese Meldung:
Nov 03 2015 11:19:20 302014 [hier stand die IP meines Laptops] 51734 192.168.32.147 443 Teardown TCP connection 9610559 for DMZ:[hier stand die IP meines Laptops]/51734 to inside:192.168.32.147/443 duration 0:00:30 bytes 0 SYN Timeout
Folgende Einstellungen habe ich dies bezüglich auf der ASA bereits vorgenommen:
Bei den Access Rules im DMZ (sozusagen outside): Source "any", Destination "Rechner des Kollegen", Service "https", Action "Permit"
Bei den Access Rules inside: Source "Rechner des Kollegen", Destination "any4", Service "ip", Action "Permit"
Bei den NAT Rules: Source Intf "inside", Dest Intf "outside" (nicht DMZ, liegt es daran? DMZ liegt zwischen Out und inside), Source "Rechner des Kollegen", Destination "any", Service "any", Source "outside".
Falls noch Informationen fehlen einfach melden.
Vielen lieben dank im vorraus!!!
Gruß
Burak
___________________________
Bild zum Kommentar
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: 287378
Url: https://administrator.de/contentid/287378
Ausgedruckt am: 22.11.2024 um 22:11 Uhr
5 Kommentare
Neuester Kommentar
Ein paar Fragen zur Zeichnung und zum Verständnis:
Was nicht geht ist das du von intern die externe IP deas NAT Routers ansprichst um auf den Server zuzugreifen. Da hast du dann ein Hairpin NAT Problem sofern du das nicht entsprechend auf der ASA konfiguriert hast ?!
http://wiki.mikrotik.com/wiki/Hairpin_NAT
- Der 3750 Switch hat keinerlei Accesslisten usw. konfiguriert ist also transparent L2 ?
- Der Webserver ist das Device was als "Intranator" bezeichnet ist ?
- Die DMZ ist das Segment indem sich "Intranator" und RZ-DMZ 2960 Switch und das ASA Interface "outside" befinden ?
- Bis zum Inside Interface der FW über die Switches 3750 und 2960 ist rein transparent L2 und kein Routing ?
- Von wo geschieht der Internet Zugriff ?? Über den Router links oben über dem "Intranator" ?
Was nicht geht ist das du von intern die externe IP deas NAT Routers ansprichst um auf den Server zuzugreifen. Da hast du dann ein Hairpin NAT Problem sofern du das nicht entsprechend auf der ASA konfiguriert hast ?!
http://wiki.mikrotik.com/wiki/Hairpin_NAT
Zu Punkt 1: Also der 3750 Switch ist ein Layer 3 switch, er routet zwischen verschiedenen subnetzten
Zu Punkt 2: Der Intranator ist ein Server, welcher unter anderem als Proxy fungiert, heißt die Mitarbeiter kommen über ihn ins internet, er klärt ab welche mitarbeiter einen zugang ins internet haben, filtert diverse inhalte im Internet u.s.w.
Der Apache Webserver läuft im Inside auf einem normalen Rechner, der Intranator hat eine öffentliche IP Addresse, über welche man auf den Webserver zugreifen kann. Er weiß das wenn jemand mit dem Port 443 (https) kommt, er an den Rechner mit dem Apache Webserver weiterleiten muss (ich muss zu geben ich kenn mich nicht wirklich mit dem Intranator aus, das macht der Kollege)
Zu Punk 3: Richtig im DMZ Segment befindet sich der Intranator, der DMZ Switch. Nicht ganz, man könnte die DMZ als zweites Inside bezeichnen, sie liegt vor der Firewall. Der Gedanke war alle Server, auf welche von "außerhalb" zugegriffen werden darf, sollen vor der Firewall liegen. (Richtig, eigentlich sollte der Apache vor die Firewall und wir sollten die Daten der Banken dann aus der DMZ ins Inside "abholen", soll aber auf Wunsch der Vorgesetzten so eingerichtet werden)
Zu Punkt 4: Siehe Punkt 1, es findet routing statt
Zu Punkt 5: Es gibt 2 verschiedene zugriffe ins Internet, der um welchen es im moment geht geschieht über den Intranator selber (heißt es fehlt sozusagen eine Linie vom Intranator ab ins Internet)
Zum Hairpin NAT:
Aber wenn ich im gleichen Netzwerk wie mein Kollege bin, unabhängig davon, im Internetbrowser die öffentliche IP Addresse (https://1.2.3.4:443) des Intranators mit entsprechendem Port eingebe um auf den Webserver zu kommen, dann verlass ich ja so zu sagen unser Netzwerk und komme ja wieder von aussen rein und werden dann wie jemand behandelt der nicht im gleichen Netzwerk ist. Wenn ich im gleichen Netz bin und https://192.168.32.147:443 eingebe, ist es klar das es funktioniert.
Ich mein, letzt endlich kann ich ja von intern die Externe ansprechen über mein Internetbrowser und es tut ja auch. Solange ich mein Rechner im internen Netzwerk habe.
Zu Punkt 2: Der Intranator ist ein Server, welcher unter anderem als Proxy fungiert, heißt die Mitarbeiter kommen über ihn ins internet, er klärt ab welche mitarbeiter einen zugang ins internet haben, filtert diverse inhalte im Internet u.s.w.
Der Apache Webserver läuft im Inside auf einem normalen Rechner, der Intranator hat eine öffentliche IP Addresse, über welche man auf den Webserver zugreifen kann. Er weiß das wenn jemand mit dem Port 443 (https) kommt, er an den Rechner mit dem Apache Webserver weiterleiten muss (ich muss zu geben ich kenn mich nicht wirklich mit dem Intranator aus, das macht der Kollege)
Zu Punk 3: Richtig im DMZ Segment befindet sich der Intranator, der DMZ Switch. Nicht ganz, man könnte die DMZ als zweites Inside bezeichnen, sie liegt vor der Firewall. Der Gedanke war alle Server, auf welche von "außerhalb" zugegriffen werden darf, sollen vor der Firewall liegen. (Richtig, eigentlich sollte der Apache vor die Firewall und wir sollten die Daten der Banken dann aus der DMZ ins Inside "abholen", soll aber auf Wunsch der Vorgesetzten so eingerichtet werden)
Zu Punkt 4: Siehe Punkt 1, es findet routing statt
Zu Punkt 5: Es gibt 2 verschiedene zugriffe ins Internet, der um welchen es im moment geht geschieht über den Intranator selber (heißt es fehlt sozusagen eine Linie vom Intranator ab ins Internet)
Zum Hairpin NAT:
Aber wenn ich im gleichen Netzwerk wie mein Kollege bin, unabhängig davon, im Internetbrowser die öffentliche IP Addresse (https://1.2.3.4:443) des Intranators mit entsprechendem Port eingebe um auf den Webserver zu kommen, dann verlass ich ja so zu sagen unser Netzwerk und komme ja wieder von aussen rein und werden dann wie jemand behandelt der nicht im gleichen Netzwerk ist. Wenn ich im gleichen Netz bin und https://192.168.32.147:443 eingebe, ist es klar das es funktioniert.
Ich mein, letzt endlich kann ich ja von intern die Externe ansprechen über mein Internetbrowser und es tut ja auch. Solange ich mein Rechner im internen Netzwerk habe.
Aber wenn ich im gleichen Netzwerk wie mein Kollege bin, unabhängig davon, im Internetbrowser die öffentliche IP Addresse (https://1.2.3.4:443) des Intranators mit entsprechendem Port eingebe um auf den Webserver zu kommen, dann verlass ich ja so zu sagen unser Netzwerk und komme ja wieder von aussen rein
Nein, das ist ein Trugschluss !Du kommst gerade bis zum Internet Router und da schlägt dann Hairpin NAT zu.
Bitte lese dir die Erklärung zu den Paket Flows bei Hairpin auf der o.a. Seite genau durch, dann verstehst du es !
Du musst eine extra ACL bzw. Policy Based Routing aktivieren auf der ASA um das zu umgehen. Oder....
eben wirklich von einem externen Host testen der NICHT im lokalen Netzwerk ist.
Zum Rest:
OK der Intranator ist also nichts anderes als ein simpler Proxy. Der gilt aber nur für Traffic der dann von inbound nach outbound geht, ist also erstmal völlig egal für das was du vorhast.
Du willst ja von außen auf den Webserver im Intranet zugreifen.
Das einfachste wäre ja natürlich den auch in die DMZ zu hängen, ihm eine öffentliche IP zu geben und gut iss. Dann wäre alles erledigt.
OK da das nicht der Fall ist musst du mit 1:1 NAT an der Firewall arbeiten:
- Öffentliche IP Adresse auf dem Internet Bein erlauben mit Access von TCP 80 und 443
- 1:1 NAT Forwarding auf die interne IP machen.
Außerdem hilft ein traceroute von der ASA auf diesen Server. Am besten mit extended Commands, dann kannst du auch die konfigurierte NAT IP Adresse als Absender eingeben und das L3 mässig wasserdicht testen !
Der Webserver sollte wenn er in einem anderen Subnetz liegt natürlich entsprechend einen Gateway Eintrag haben bzw. das Gateway dann auf die Firewall zeigen die auch das statische 1:1 NAT für diesen Server hält, logisch !
Wie gesagt, denk an das Hairpin NAT das funktioniert nicht wenn du eine externe IP ansprichst von intern und kein PBR und die entsprechenden ACL aktiviert hast auf der ASA !
Schon gar nicht wenn das dann auch noch über einen Zwnagsproxy geht wie bei euch.
Habs Problem gelöst, ich versuchs am Montag von der Arbeit aus zu erklären (Y)
Wir warten noch immer auf die spannende Lösung zu diesem Problem....??
