4
Problem mit NAT - VPN Zugang Cisco ASA 5500
Hallo zusammen,
ich bin neu an Bord und hoffe einen guten Anschluss bei Administrator.de. zu finden.
Ich bin alleiniger Administrator in einer eher kleinen Anwaltskanzlei und hoffe mein Wissen hier erweitern zu können, als auch Erfahrungen und Wissen mit anderen zu teilen. Das ganze Netzwerk wurde vorher von einem externen Dienstleister gehostet und haben uns nun entschlossen das Netzwerk Thema langsam selbst zu übernehmen.
Ich stehe Momentan an einem Problem mit dem VPN Zugang zu einem unserer Mandanten fest.
Wir haben eine Cisco ASA 5500 und haben eine erfolgreich stehende IP Sec Verbindung zur gegenüberliegenden Peer Adresse.
Der Mandant bat nach einer IP, die uns gehört, die er für das gegenüberliegende Netzwerk auf seiner Firewall für den VPN Tunnel freischaltet wird.
Er akzeptiert keine privaten IP Adressen. Deswegen haben wir eine Public IP von unserem DSL Anbieter 89.101.253.55. rausgesucht.
Nur ein Mitarbeiter von uns wird den Zugang zu deren Server brauchen. Das ganze sollte dann so aussehen, dass seine Client IP 10.215.70.60, durch unsere ASA, ein Source NAT zum Zielnetzwerk 213.217.54.230 /27 bekommt.
Die ganze Konstruktion sieht folgendermaßen aus:
Unser Interface an der ASA (Public IP) z.B. 89.101.253.54
89.101.253.55 soll getunnelt werden. Das ist eine zusätzliche IP von der Telekom.
Interne ASA IP: 10.215.0.1
Core Switch: 10.215.0.10 hängt direkt an der ASA (ASA ist ihr Default Gateway)
Zusätzlich hängt an dem Core Switch ein VLAN 70. Das Gateway des VLANS 10.215.70.254
An dem Core Switch hängt ein weiterer Switch der per Tagged VLAN mit dem Core Switch verbunden ist.
Daran hängt dann der Client. Unser Client: 10.215.70.60
Hat als Standardgateway den 10.215.70.254.
Mandanten Peer ID:
89.200.453.20
Network: 213.217.54.230 /27
IP des zu erreichenden Servers: 213.217.54.233
Wenn ich einen Ping über TCP Port 17500 (nur der wurde freigeschaltet), über die Cisco ASA auf die 213.217.54.233 absetze,
mit der Absender IP: 89.101.253.55, dann bekomme ich auch eine Antwort.
Das Problem liegt jetzt darin, dass der Client keine Verbindung aufbauen kann. Auch mit einem Telnet auf 213.217.54.233 mit dem Port 17500 kann ich keine Verbindung aufbauen, was nach der Aussage des Admins vom Partner, funktionieren sollte.
Ich schätze ich hab einfach einen Denkfehler im NAT Vorgang oder ähnliches
Eingestellt wurde als NAT Rule:
Host 10.215.70.60 > Source Nat / Dynamic PAT auf 89.101.253.55 > Destination Address 213.217.54.230 /27.
Das ganze wurde dann noch für beide Seiten eingestellt. Für Service wurde bei Source sowie Destination Address "any" ausgewählt sowie auch für das Interface. Hab es aber auch schon mit dem Telekom Interface (89.101.253.54) ausprobiert.
1. Frage: Ist das überhaupt notwendig? Theoretisch gesehen brauche ich nur eine NAT Regel von unserem Host zu deren Netz, wo die Absender Adresse in 89.101.253.55 abgeändert
2. Frage: Findet das Paket auch den Weg zurück? Das Paket müsste ja an die 89.101.253.55 zurück kommen, da diese ja in der ersten NAT Regel gesendet hat. Dabei müsste ich doch noch eine NAT Regel erstellen, wo die Zieladresse wieder in 10.215.70.60 abgeändert wird, oder?
Heißt: Source Address: 213.217.54.230 /27 > Destination Address: 89.101.253.55 <<<< Destination NAT auf 10.215.70.60?
Das Routing übernimmt auch die Cisco ASA. Da werden alle Routen für z.B. 10.215.70.0 /24 auf 10.215.0.10 geroutet. Das müsste ja weiterhin passen und reichen?
Ich hoffe das Ganze ist Verständlich ausgedrückt worden. Der User wird langsam ungeduldig und braucht dringend den Zugang....
Ist eine Web Applikation, die er über den Browser per http und der IP Adresse sowie Port aufrufen soll.
Vielen Dank im Voraus
ich bin neu an Bord und hoffe einen guten Anschluss bei Administrator.de. zu finden.
Ich bin alleiniger Administrator in einer eher kleinen Anwaltskanzlei und hoffe mein Wissen hier erweitern zu können, als auch Erfahrungen und Wissen mit anderen zu teilen. Das ganze Netzwerk wurde vorher von einem externen Dienstleister gehostet und haben uns nun entschlossen das Netzwerk Thema langsam selbst zu übernehmen.
Ich stehe Momentan an einem Problem mit dem VPN Zugang zu einem unserer Mandanten fest.
Wir haben eine Cisco ASA 5500 und haben eine erfolgreich stehende IP Sec Verbindung zur gegenüberliegenden Peer Adresse.
Der Mandant bat nach einer IP, die uns gehört, die er für das gegenüberliegende Netzwerk auf seiner Firewall für den VPN Tunnel freischaltet wird.
Er akzeptiert keine privaten IP Adressen. Deswegen haben wir eine Public IP von unserem DSL Anbieter 89.101.253.55. rausgesucht.
Nur ein Mitarbeiter von uns wird den Zugang zu deren Server brauchen. Das ganze sollte dann so aussehen, dass seine Client IP 10.215.70.60, durch unsere ASA, ein Source NAT zum Zielnetzwerk 213.217.54.230 /27 bekommt.
Die ganze Konstruktion sieht folgendermaßen aus:
Unser Interface an der ASA (Public IP) z.B. 89.101.253.54
89.101.253.55 soll getunnelt werden. Das ist eine zusätzliche IP von der Telekom.
Interne ASA IP: 10.215.0.1
Core Switch: 10.215.0.10 hängt direkt an der ASA (ASA ist ihr Default Gateway)
Zusätzlich hängt an dem Core Switch ein VLAN 70. Das Gateway des VLANS 10.215.70.254
An dem Core Switch hängt ein weiterer Switch der per Tagged VLAN mit dem Core Switch verbunden ist.
Daran hängt dann der Client. Unser Client: 10.215.70.60
Hat als Standardgateway den 10.215.70.254.
Mandanten Peer ID:
89.200.453.20
Network: 213.217.54.230 /27
IP des zu erreichenden Servers: 213.217.54.233
Wenn ich einen Ping über TCP Port 17500 (nur der wurde freigeschaltet), über die Cisco ASA auf die 213.217.54.233 absetze,
mit der Absender IP: 89.101.253.55, dann bekomme ich auch eine Antwort.
Das Problem liegt jetzt darin, dass der Client keine Verbindung aufbauen kann. Auch mit einem Telnet auf 213.217.54.233 mit dem Port 17500 kann ich keine Verbindung aufbauen, was nach der Aussage des Admins vom Partner, funktionieren sollte.
Ich schätze ich hab einfach einen Denkfehler im NAT Vorgang oder ähnliches
Eingestellt wurde als NAT Rule:
Host 10.215.70.60 > Source Nat / Dynamic PAT auf 89.101.253.55 > Destination Address 213.217.54.230 /27.
Das ganze wurde dann noch für beide Seiten eingestellt. Für Service wurde bei Source sowie Destination Address "any" ausgewählt sowie auch für das Interface. Hab es aber auch schon mit dem Telekom Interface (89.101.253.54) ausprobiert.
1. Frage: Ist das überhaupt notwendig? Theoretisch gesehen brauche ich nur eine NAT Regel von unserem Host zu deren Netz, wo die Absender Adresse in 89.101.253.55 abgeändert
2. Frage: Findet das Paket auch den Weg zurück? Das Paket müsste ja an die 89.101.253.55 zurück kommen, da diese ja in der ersten NAT Regel gesendet hat. Dabei müsste ich doch noch eine NAT Regel erstellen, wo die Zieladresse wieder in 10.215.70.60 abgeändert wird, oder?
Heißt: Source Address: 213.217.54.230 /27 > Destination Address: 89.101.253.55 <<<< Destination NAT auf 10.215.70.60?
Das Routing übernimmt auch die Cisco ASA. Da werden alle Routen für z.B. 10.215.70.0 /24 auf 10.215.0.10 geroutet. Das müsste ja weiterhin passen und reichen?
Ich hoffe das Ganze ist Verständlich ausgedrückt worden. Der User wird langsam ungeduldig und braucht dringend den Zugang....
Ist eine Web Applikation, die er über den Browser per http und der IP Adresse sowie Port aufrufen soll.
Vielen Dank im Voraus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 294781
Url: https://administrator.de/contentid/294781
Printed on: April 18, 2024 at 09:04 o'clock
4 Comments
Latest comment
Etwas ist hier IP technisch unverständlich....
Die .55 ist immer eine Hostadresse oder ein Broadcast. Wie kommst du hier auf ein "Netzwerk" ??
Nur mal soviel zu den Fragen:
1.)
Nein, vermutlich nicht, denn die 89er Adressen (die witzigerweise in Irland liegen ?!) gelten ja nur für die Tunnelendpunkte des VPN Tunnels wenn man deine Ausführungen richtig deutet. Die sind für das NAT und die Erreichbarkeit der lokalen internen LAN vollig unerheblich.
Ganz klar ist deine Darstellung allerdings dazu nicht. Ggf. hilft hier eine Skizze.
2.)
Das kommt darauf an. Wenn das geNATete Netzwerk am Ziel bekannt ist sprich eine Route dahin besteht dann ja. Ein sh ip route auf dem Cisco beantwortet dir diese Frage in Sekunden...
Leider ist weder klar ob du ein VPN Client Dialin machst oder ob du eine LAN 2 LAN Kopplung realisiert hast, geschweige denn welches VPN Protokoll.
Network: 89.101.253.55 das getunnelt wird
Es gibt kein Netzwerk weder mit einerm /29 (oder kleiner) noch mit einem /30er Prefix was hier passt.Die .55 ist immer eine Hostadresse oder ein Broadcast. Wie kommst du hier auf ein "Netzwerk" ??
Nur mal soviel zu den Fragen:
1.)
Nein, vermutlich nicht, denn die 89er Adressen (die witzigerweise in Irland liegen ?!) gelten ja nur für die Tunnelendpunkte des VPN Tunnels wenn man deine Ausführungen richtig deutet. Die sind für das NAT und die Erreichbarkeit der lokalen internen LAN vollig unerheblich.
Ganz klar ist deine Darstellung allerdings dazu nicht. Ggf. hilft hier eine Skizze.
2.)
Das kommt darauf an. Wenn das geNATete Netzwerk am Ziel bekannt ist sprich eine Route dahin besteht dann ja. Ein sh ip route auf dem Cisco beantwortet dir diese Frage in Sekunden...
Das Routing übernimmt auch die Cisco ASA
Auf beiden Seiten oder wie ist das jetzt gemeint ??Leider ist weder klar ob du ein VPN Client Dialin machst oder ob du eine LAN 2 LAN Kopplung realisiert hast, geschweige denn welches VPN Protokoll.
Ich hoffe das Ganze ist Verständlich ausgedrückt worden.
Leider nein...eher das Gegenteil ist der Fall. Du solltest hier besser eine kurze Skizze über die Bilder Upload Funktion posten, damit das technisch klar wird.
Vielen Dank schonmal für die schnelle Antwort. Bild wurde im Beitrag eingefügt. Hoffe, dass es jetzt ein bisschen deutlicher wird und hilft.
89.101.253.55 soll getunnelt werden. Habe mich da missverständlich ausgedrückt.
Das ist eine zusätzliche IP von der Telekom.Diese mussten wir nehmen, da die gegnerische Seite keine IP Adressen aus dem privaten Adressbereich akzeptiert. Die haben wohl viele VPN Verbindungen mit anderen Firmen und arbeiten deswegen wohl nur mit öffentlichen IP Adressen.
Es handelt sich hier um eine IP Sec Site to Site Verbindung mit der Cisco ASA. Der tunnel steht auch schon und es gehen auch Pakete durch.
Wenn ich einen Ping auf 213.217.54.233, mit der IP 89.101.253.55 und mit dem Port 17500 absetze, geht das ganze auch Erfolgreich durch.
Jetzt muss ich nur hinkriegen, dass der Client ( 10.215.70.60 ) das Paket auch absetzen kann. Und das als ""89.101.253.55 und das Paket auch wieder zum Client (10.215.70.60) ankommt.
89.101.253.55 soll getunnelt werden. Habe mich da missverständlich ausgedrückt.
Das ist eine zusätzliche IP von der Telekom.Diese mussten wir nehmen, da die gegnerische Seite keine IP Adressen aus dem privaten Adressbereich akzeptiert. Die haben wohl viele VPN Verbindungen mit anderen Firmen und arbeiten deswegen wohl nur mit öffentlichen IP Adressen.
Es handelt sich hier um eine IP Sec Site to Site Verbindung mit der Cisco ASA. Der tunnel steht auch schon und es gehen auch Pakete durch.
Wenn ich einen Ping auf 213.217.54.233, mit der IP 89.101.253.55 und mit dem Port 17500 absetze, geht das ganze auch Erfolgreich durch.
Jetzt muss ich nur hinkriegen, dass der Client ( 10.215.70.60 ) das Paket auch absetzen kann. Und das als ""89.101.253.55 und das Paket auch wieder zum Client (10.215.70.60) ankommt.
Fehler gefunden. Das Problem lag die ganze Zeit daran, dass eine übergeordnete NAT Regel seine Host Adresse schon in ein anderes VPN Netzwerk genattet hatte. Habe diese NAT Regel jetzt vor der ersten geschoben.
Jetzt frage ich mich nur, ob es nicht theoretisch auch möglich wäre, dass beide NAT Regeln, je nachdem welche IP erreicht werden soll, funktionieren.
Jetzt frage ich mich nur, ob es nicht theoretisch auch möglich wäre, dass beide NAT Regeln, je nachdem welche IP erreicht werden soll, funktionieren.
Ja das geht natürlich kinderleicht mit einem Cisco. Mach das genauso wie bei PBR mit einer ACL Liste bzw. Route Map die den Traffic klassizifiziert und abhängig davon dann forwardet.
Beispiel findest du hier:
Cisco Router 2 Gateways für verschiedene Clients
Beispiel findest du hier:
Cisco Router 2 Gateways für verschiedene Clients
1
