Cisco ASA VPN für Remote-Client-Verbindung in das interne Netz
Hallo zusammen,
ich habe eine Frage an Euch für ein generelles Verständnis. Dazu sei folgender, anonymisierter Aufbau gegeben (siehe Grafik).
Vorab:
Ich würde gerne wissen, wie die Kommunikation aus einem VPN-Netz unter der Nutzung von NAT in das interne Netz funktioniert.
Kurze Beschreibung des Aufbaus:
An dem Catalyst 3560 liegen die Netze 192.168.16.0/24, 192.168.17.0/24 sowie 192.168.18.0/24 an. Das Routing wird mittels Inter-VLAN-Routing an diesem Switch ermöglicht.
Das Netz 192.168.19.0/24 wird zwischen dem Catalyst 3560 und der ASA 5500 genutzt - wohlgemerkt ohne VLAN-Trunking-Verbindung, denn VLANs werden in der Ausbaustufe der ASA leider nicht unterstützt.
Das Netz 192.168.1.0/24 wird zwischen der ASA 5500 und dem Internetrouter Cisco 876 eingesetzt.
Für Internetverbindungen von innen (z.B. 192.168.18.0/24) nach außen (Internet) wird sowohl auf der ASA 5500 als auch auf dem Cisco 876 NAT eingesetzt.
Der VPN-Concentrator für Verbindungen von außen nach innen befindet sich in der ASA. Der Internetrouter (Cisco 876) reicht IPSEC-VPN-Anfragen an die ASA weiter. VPN-Clients landen im Netz 192.168.20.0/24.
Meine Frage ist nun folgende:
Wie kann ein VPN-Client, der beispielsweise die Adresse 192.168.20.1 erhält, eine Kommunikation in ein internes Netz (z.B. 192.168.17.0/24) ausführen.
Der VPN-Client hat nach meiner Vorstellung gar keine Routing-Information, um das Netz 192.168.17.0/24 zu erreichen - schließlich gibt es kein "Router-Interface" im VPN-Netz (192.168.20.0/24).
Derzeit konfiguriere ich eine Firewall, bei der genau dieser Aufbau funktioniert. Jedoch kann ich das nicht nachvollziehen, denn nach meinem Verständnis bräuchte man normalerweise einen Router mit Interface im VPN-Netz (192.168.20.9/24).
Darüber hinaus habe ich bei diesem Aufbau das Problem, dass keine Firewall-Policy (Filterregel) greift, um die Kommunikation aus dem Netz 192.168.20.0/24 in das Netz 192.168.17.0/24 zu verhindern. Ich habe die Kommunikation nicht explizit erlaubt. Selbst wenn ich Deny-Regeln einbinde, greifen diese nicht.
Kann es sein, dass durch NATing für die Kommunikation aus dem VPN-Netz in das interne Netz Filterregeln nicht greifen und es quasi einen Pass-Through gibt?
Leider kann ich die Konfiguration hier nicht aufführen, da ich die entsprechenden Teile wegen der Anonymisierung umschreiben müsste und mir zudem nicht ganz klar ist, welche Teile davon relevant sind.
Ich hoffe, dass dennoch jemand etwas zu dem Phänomen sagen kann und vielleicht auch wie ihr generell eine Umsetzung durchführen würdet, um aus dem VPN-Netz in das interne Netz zu gelangen.
solange kein splittunneling verwendet wird, wird mal alles an die Firewall geschickt solange die VPN verbindung aufrecht ist. Und die FW kennt die Route zu deinen netzen klarerweise und für jeden VPN Client gibts ne Hostroute.
Ich vermute "sysopt connection permit-ipsec" ist aktiv, daher können deine VPN Clients überall hin. Wobei ich jetzt nicht weiß welche Regeln du da jetzt genau meinst, acl am Interface oder Regeln die via ACS pro User zugewiesen werden ?
Warum du doppelt nattest ist mir ein Rätsel, die Grafik ist zwar noch nicht freigeschaltet, aber wenn das so läuft wie ich das hier rauslese ist es höchste Eisenbahn ein offizielles Linknetz zwischen Router und ASA zu fahren um diesen Unsinn ein Ende zu bereiten. Der Router sollte dann nur mehr routen/modem spielen,alles andere passiert auf der ASA.
...Meine Frage ist nun folgende:
Der VPN-Client hat nach meiner Vorstellung gar keine Routing-Information, um das Netz 192.168.17.0/24 zu erreichen - schließlich gibt es kein "Router-Interface" im VPN-Netz (192.168.20.0/24).
Der VPN-Client bekommt alle notwendigen Informationen von der ASA.
Wenn also die ASA die Netze hinter Deinem Switch erreichen kann, musst Du die entsprechenden Regeln für den zugewiesenen VPN-Pool einrichten, um von diesem IP-Pool in die Netze 16/17/18 zu kommen. Einfacherweise nimmst Du das NAT für diese Verbindung raus.
@hegl:
Okay, das ist gut zu wissen. Mir war nicht bewusst, dass die VPN-Lösung solche Aufgaben übernimmt.
@Otaku19:
Deinen Hinweis werde ich berücksichtigen. Könntest Du mir genauer sagen, wie Du die Verbindung zwischen ASA und Router ändern würdest?
Mir ist nicht klar, wie ich das doppelte NATing (bzw. NAT auf dem Router) umgehen kann, da der Router die Internetverbindung aufbaut und somit die einzige nach außen bekannte IP-Adresse besitzt.
Gerade bin ich mir auch nicht ganz sicher, ob die ASA für Internetverbindungen überhaupt NATing durchführt. Ich meine sogar fast, dass sie nur NATing für VPN nutzt, aber das müsste ich nochmal prüfen.
du kannst das alleien nur schwer umbauen, dein ISP müsste dir noch mindestens ein /30 Netz routen, dieses netz wird dann n zwischen Router und Firewall gefahren. Die ASA sollte grade als VPN Endpunkt mit einer öffentlichen IP betrieben werden, abgesehen davon hat sie einfach mehr Dampf als der 876er iirc
Deine Idee werde ich in Zukunft berücksichtigen. Nur derzeit reicht die Performance dieses Aufbaus noch.
Folgende Frage hätte ich noch zusätzlich.
Und zwar soll der in der Grafik gezeigte Aufbau für eine Site-To-Site-Verbindung auf IPSec-Basis genutzt werden.
Die Gegenstelle stellt folgende Anforderung.
VPN-Endpoint (auf deren Seite): 194.1.1.1 (verfremdet)
Deren VPN-Netz: 194.1.1.0/27
Unser öffentlicher Endpunkt: x.x.x.x (wird durch NATing auf die ASA als tatsächlicher VPN-Endpunkt 192.168.1.2 gemappt)
Das zu erreichende System: 192.168.16.150/32
Was die Gegenseite möchte ist, dass sie das zu erreichende System über die Adresse 10.1.1.1/32 erreichen.
Nach meinem Verständnis muss auf der ASA für diesen Zweck NATing durchgeführt werden. Das System 192.168.16.150 wird quasi nach außen hin versteckt, richtig?
Funktioniert das so auf diesem Weg? Wenn ja, welchen Eintrag muss ich dafür setzen?
Ist dieser Eintrag korrekt?
static (inside,outside) 10.1.1.1 192.168.15.150 netmask 255.255.255.255 0 0
