2
Site-to-Site-VPN und Cisco VPN-Client von gleicher IP
Hallo Forum und Cisco-ASA-Spezialisten,
ich habe folgendes Szenario (und im Internet leider nichts Passendes gefunden):
Cisco ASA (Standort A)
Sophos Firewall (Standort B)
Ohne hier die konkrete Konfiguration erfragen zu wollen: geht sowas überhaupt und wo müsste ich auf der ASA ansetzen?
Danke schonmal
Horst
ich habe folgendes Szenario (und im Internet leider nichts Passendes gefunden):
- zwei Standorte A und B sind über Site-to-Site-VPN verbunden. Nur benötigte Ports sind geöffnet.
- In Standort B werden "fremde" Netzwerk-Geräte (dazu gehören auch Laptops aus Standort A) ins Gästenetz mit Internetverbindung umgeleitet.
- Um auf Standort A zuzugreifen, soll mittels Cisco VPN Client aus dem Gästenetz von Standort B eine VPN-Verbindung aufgebaut werden.
- Da aber die Public IP von Standort B für das Gästenetz die gleiche ist wie für den Site-to-Site-Tunnel, scheitert der Verbindungsaufbau auf der ASA.
Cisco ASA (Standort A)
Sophos Firewall (Standort B)
Ohne hier die konkrete Konfiguration erfragen zu wollen: geht sowas überhaupt und wo müsste ich auf der ASA ansetzen?
Danke schonmal
Horst
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: 323131
Url: https://administrator.de/forum/site-to-site-vpn-und-cisco-vpn-client-von-gleicher-ip-323131.html
Ausgedruckt am: 27.12.2024 um 19:12 Uhr
2 Kommentare
Neuester Kommentar
Leider schreibst du nicht welches VPN Protokoll die LAN2LAN Verbindung realisiert aber wir raten mal das es vermutlich IPsec ist.
Das Konstrukt krankt daran daran es schon eine Tunnelkopplung gibt jetzt aber zusätzlich aus dem LAN nochmal einen VPN Client Konfig gemacht werden soll. Und das vermutlich auch wieder mit dem gleichen VPN Protokoll, richtig ?
Das ist letztlich der gravierende Design Fehler an dem es scheitern wird.
Man würde es hinbekommen aber nur mit erheblichen Klimmzügen an der Konfig. Ob das dann sauber rennt in einer heterogenen VPN Umgebung wäre dann nich zu klären.
Die grundsätzliche Frage die man sich hier stellen muss ist warum eigentlich betriebsinterne Rechner im eigenen Netz als "fremd" deklariert werden ??
Eigentlich ja Quatsch und zeigt auch den eigentlichen Fehler auf. Bzw. wirft dann die nächste Frage auf WIE denn überhaupt diese Erkennung lokal und fremd gemacht wird ?
Ein Netzwerker macht sowas über 802.1x oder Mac Bypass am Switch und kann dann sauber erkennen das das eben keine fremden Rechner sind sondern eigenen und konfiguriert dann den Switchports ins richtige (interne) VLAN der dann normal über den Site to Site Tunnel nach "drüben" geroutet wird.
So würde man es richtig machen.
Der Workaround sieht dann so aus das du die "fremden" Laptops aus A sicher per Mac Nailing am DHCP Server identifizierst und ihnen feste IPs im Gastnetz gibst. Über eine ACL kann man diese dann per Source NAT in den VPN Tunnel hieven.
Ein erheblicher Aufwand der das Management der Router unnötig verkompliziert.
Genausogut könnte man diesen Geräten über Mac Nailing IPs aus dem "normalen" Netz zuweisen oder noch besser wie oben gesagt über .1x dynamisch ins interne Netz heben.
Ob man das dann mit einem separaten "Gast aus Standort A" VLAN macht indem nur die betreibsinternen "Gäste" sind oder üer das normale Netzwerk an Standort B ist eine Security Frage.
Beides ist möglich und wäre der sinnvollere Weg hier.
Das Konstrukt krankt daran daran es schon eine Tunnelkopplung gibt jetzt aber zusätzlich aus dem LAN nochmal einen VPN Client Konfig gemacht werden soll. Und das vermutlich auch wieder mit dem gleichen VPN Protokoll, richtig ?
Das ist letztlich der gravierende Design Fehler an dem es scheitern wird.
Man würde es hinbekommen aber nur mit erheblichen Klimmzügen an der Konfig. Ob das dann sauber rennt in einer heterogenen VPN Umgebung wäre dann nich zu klären.
Die grundsätzliche Frage die man sich hier stellen muss ist warum eigentlich betriebsinterne Rechner im eigenen Netz als "fremd" deklariert werden ??
Eigentlich ja Quatsch und zeigt auch den eigentlichen Fehler auf. Bzw. wirft dann die nächste Frage auf WIE denn überhaupt diese Erkennung lokal und fremd gemacht wird ?
Ein Netzwerker macht sowas über 802.1x oder Mac Bypass am Switch und kann dann sauber erkennen das das eben keine fremden Rechner sind sondern eigenen und konfiguriert dann den Switchports ins richtige (interne) VLAN der dann normal über den Site to Site Tunnel nach "drüben" geroutet wird.
So würde man es richtig machen.
Der Workaround sieht dann so aus das du die "fremden" Laptops aus A sicher per Mac Nailing am DHCP Server identifizierst und ihnen feste IPs im Gastnetz gibst. Über eine ACL kann man diese dann per Source NAT in den VPN Tunnel hieven.
Ein erheblicher Aufwand der das Management der Router unnötig verkompliziert.
Genausogut könnte man diesen Geräten über Mac Nailing IPs aus dem "normalen" Netz zuweisen oder noch besser wie oben gesagt über .1x dynamisch ins interne Netz heben.
Ob man das dann mit einem separaten "Gast aus Standort A" VLAN macht indem nur die betreibsinternen "Gäste" sind oder üer das normale Netzwerk an Standort B ist eine Security Frage.
Beides ist möglich und wäre der sinnvollere Weg hier.
Vielen Dank für Deine ausführliche Antwort.
Die "fremden" Rechner resultieren aus Zukauf von Standort A durch Standort B. Die Umleitung ins Gästenetz erfolgt wie Du vermutest auf dem Switch. Ich werde Deinen Workaround mal versuchen.
Nochmals Dank und einen schönen Abend.
Horst
Die "fremden" Rechner resultieren aus Zukauf von Standort A durch Standort B. Die Umleitung ins Gästenetz erfolgt wie Du vermutest auf dem Switch. Ich werde Deinen Workaround mal versuchen.
Nochmals Dank und einen schönen Abend.
Horst
