7
Cisco IPsec S2S-VPN ohne Routen am default GW oder Client
Hallo,
Ich habe folgende Situation:
(Außenstandort Cisco 867) --------------------------------> (Zentrale Cisco C881)
(192.168.1.0/24) ----------------------------------> (192.168.0.0/24)
ich habe einen S2S-VPN zwischen zwei Routern (Cisco 881 und Cisco 867) gespannt, jedoch habe ich nun das Problem dass die Clients der Zentrale den Weg zurück zum Außenstandort nicht finden, da der Cisco C881 welcher den VPN Terminiert nicht das Default Gateway der Clients ist, dieser hängt quasi nur im Subnetz um den VPN zu terminieren. Es ist nicht möglich am Gateway in der Zentrale routen zurück zu setzen oder direkt lokal am Client.
Jetzt habe ich versucht das Netz ankommende Netz statisch vom Außenstandort am Zentralenrouter inside zu natten, was auch funktioniert. (192.168.1.5 -->192.168.0.5)
Jedoch funktioniert das Outside NAT (Weg zurück) nicht da der Client mit einem ARP-Request im Zentralennetz nach der MAC-Adresse des Clients am Außenstandort fragt, und diese so durchs NAT nicht erfährt.
Ich weiß das dies eine ziemlich außergewöhnliche Konfiguration ist und keinesfalls empfehlenswert, es geht nur vorübergehend nicht anders.
Hat jemand eine Idee wie ich das Lösen könnte?
Freundliche Grüße
Ich habe folgende Situation:
(Außenstandort Cisco 867) --------------------------------> (Zentrale Cisco C881)
(192.168.1.0/24) ----------------------------------> (192.168.0.0/24)
ich habe einen S2S-VPN zwischen zwei Routern (Cisco 881 und Cisco 867) gespannt, jedoch habe ich nun das Problem dass die Clients der Zentrale den Weg zurück zum Außenstandort nicht finden, da der Cisco C881 welcher den VPN Terminiert nicht das Default Gateway der Clients ist, dieser hängt quasi nur im Subnetz um den VPN zu terminieren. Es ist nicht möglich am Gateway in der Zentrale routen zurück zu setzen oder direkt lokal am Client.
Jetzt habe ich versucht das Netz ankommende Netz statisch vom Außenstandort am Zentralenrouter inside zu natten, was auch funktioniert. (192.168.1.5 -->192.168.0.5)
Jedoch funktioniert das Outside NAT (Weg zurück) nicht da der Client mit einem ARP-Request im Zentralennetz nach der MAC-Adresse des Clients am Außenstandort fragt, und diese so durchs NAT nicht erfährt.
Ich weiß das dies eine ziemlich außergewöhnliche Konfiguration ist und keinesfalls empfehlenswert, es geht nur vorübergehend nicht anders.
Hat jemand eine Idee wie ich das Lösen könnte?
Freundliche Grüße
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: 325281
Url: https://administrator.de/contentid/325281
Printed on: April 24, 2024 at 02:04 o'clock
7 Comments
Latest comment
Moin,
wer macht denn im Außenstandort das Gateway?
denn hier musst du ja eine Route dann setzen, wenn ich mich recht entsinne.
wenn dein 867 in dem besagten Netz z.B. die 192.168.1.2 hätte und das Gateway die 192.168.1.1, so müsstest du am Gateway eine Route setzen, die das Netz 192.168.0.0/24 auf den 192.168.1.2 verweist...
Denn woher soll denn sonst jemand wissen, wohin die Pakete zu senden sind...
Gruß
em-pie
wer macht denn im Außenstandort das Gateway?
denn hier musst du ja eine Route dann setzen, wenn ich mich recht entsinne.
wenn dein 867 in dem besagten Netz z.B. die 192.168.1.2 hätte und das Gateway die 192.168.1.1, so müsstest du am Gateway eine Route setzen, die das Netz 192.168.0.0/24 auf den 192.168.1.2 verweist...
Denn woher soll denn sonst jemand wissen, wohin die Pakete zu senden sind...
Gruß
em-pie
Die hiesigen Tutorials zu dem Thema hast du gelesen ?
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Und siehe auch: Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Dort ist eigentlich genau erklärt was zu machen ist.
Vermutlich hast du die ACL vergessen oder falsch konfiguriert die den Tunneltraffic definiert für die Clients, kann das sein ?
Das ist so als wenn du zum Mond fliegen willst aber keine Rakete hast...
Vergiss es...ohne das ist das niemals umsetzbar ! Wie auch. Die Routen sind essentiall zur Wegefindung.
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Und siehe auch: Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Dort ist eigentlich genau erklärt was zu machen ist.
Vermutlich hast du die ACL vergessen oder falsch konfiguriert die den Tunneltraffic definiert für die Clients, kann das sein ?
Es ist nicht möglich am Gateway in der Zentrale routen zurück zu setzen oder direkt lokal am Client.
Das ist allerdings tödlich ! Damit fehlt jegliche Grundvoraussetzung sowas umzusetzen.Das ist so als wenn du zum Mond fliegen willst aber keine Rakete hast...
Vergiss es...ohne das ist das niemals umsetzbar ! Wie auch. Die Routen sind essentiall zur Wegefindung.
Hallo max,
neben dem ARP-Eintrag wird noch eine statische Hostroute gebraucht, denn der Router in der Zentrale führt das NAT erst nach dem Routing durch. Dazu musst du die NAT-Regel um den Eintrag "add-route" erweitern.
Ohne diesen Eintrag erstellt der Router zwar einen ARP-Eintrag auf dem "inside-interface", aber routet Pakete an die 192.168.0.5 nicht zum "outside-interface", wo zuerst NAT (in diesem Fall das Umschreiben der Dst-Addr auf 192.168.1.5) und danach die Verarbeitung gemäß der IPSec-Policy stattfinden.
Werden Pakete aus dem LAN der Außenstelle (192.168.1.5) empfangen ist nichts weiter zu beachten, da hier nur die Src-Addr umgeschrieben wird und ein Routingeintrag für das Ziel (das LAN der Zentrale) zwangsläufig existiert.
BB
neben dem ARP-Eintrag wird noch eine statische Hostroute gebraucht, denn der Router in der Zentrale führt das NAT erst nach dem Routing durch. Dazu musst du die NAT-Regel um den Eintrag "add-route" erweitern.
ip nat outside source 192.168.1.5 192.168.0.5 add-routeOhne diesen Eintrag erstellt der Router zwar einen ARP-Eintrag auf dem "inside-interface", aber routet Pakete an die 192.168.0.5 nicht zum "outside-interface", wo zuerst NAT (in diesem Fall das Umschreiben der Dst-Addr auf 192.168.1.5) und danach die Verarbeitung gemäß der IPSec-Policy stattfinden.
Werden Pakete aus dem LAN der Außenstelle (192.168.1.5) empfangen ist nichts weiter zu beachten, da hier nur die Src-Addr umgeschrieben wird und ein Routingeintrag für das Ziel (das LAN der Zentrale) zwangsläufig existiert.
BB
1
Das Problem bleibt aber das die Clients ein anderes Default Gateway haben und er auf dem Default Gateway und auch auf den Clients selber nichts konfigurieren kann.
Die Wegefindung im L3 wird das also auch nicht lösen...leider. Unter den o.a. Voraussetzungen des TOs hat man ja keinerlei Chance dem Client oder dem Default Gate der Clients zu sagen wo die Pakete lang müssen um ins Standort VPN zu kommen.
Die Wegefindung im L3 wird das also auch nicht lösen...leider. Unter den o.a. Voraussetzungen des TOs hat man ja keinerlei Chance dem Client oder dem Default Gate der Clients zu sagen wo die Pakete lang müssen um ins Standort VPN zu kommen.
Zitat von @aqui:
Das Problem bleibt aber das die Clients ein anderes Default Gateway haben und er auf dem Default Gateway und auch auf den Clients selber nichts konfigurieren kann.
Weil er das eben nicht kann, möchte er als Notlösung eine IP-Adresse aus dem LAN der Zentrale nehmen und sie "natten". Auf einem PC in der Zentrale könnte er zum Beispiel ein Laufwerk aus dem Netz der Außenstelle mounten und dieses im LAN freigeben. Beispielsweise kann ein PC als DA die 192.168.0.5 nehmen , die der Router auf die 192.168.1.5 umschreibt.Das Problem bleibt aber das die Clients ein anderes Default Gateway haben und er auf dem Default Gateway und auch auf den Clients selber nichts konfigurieren kann.
Das ist der Sinn seiner Frage. Er möchte also nicht ohne Rakete auf den Mond fliegen, sondern nur das nutzen, was ein IOS-Router kann. Zumindest verstehe ich sein Anliegen so.
BB
OK, Da hast du natürlich vollkommen Recht.
Das habe ich dann missverstanden bzw. "überlesen" das da jetzt NAT im Spiel ist...sorry !
Mit NAT ist das natürlich so möglich, keine Frage !
Das habe ich dann missverstanden bzw. "überlesen" das da jetzt NAT im Spiel ist...sorry !
Mit NAT ist das natürlich so möglich, keine Frage !
Hallo, das add Route wars!
Vielen Dank für eure Hilfe, nun läufts.
Lg
Vielen Dank für eure Hilfe, nun läufts.
Lg
