6
Site-to-Site VPN zwischen 2 identischen Subnetzen
Hallo,
ich habe gerade die undankbare Aufgabe bekommen, unser Supportnetz (10.10.10.0/24) mit einem Kundennetz (10.0.0.0/8) per Site-to-Site VPN verbinden zu dürfen.
Die Verbindung zwischen den Peers läuft erwartungsgemäß einwandfrei und genauso erwartungsgemäß kollidieren die beiden Netze beim Routing miteinander. Der Kunde weicht keinen Millimeter von seiner Maximalforderung ab, auf seiner Seite das 10er Netz als Class-A Netz zu betreiben. Genauso wenig kann ich bei mehr als hundert Site-to-Site Verbindungen unser Netz umstellen.
Ich habe gehört, dass es wohl möglich ist, den Traffic im Tunnel zu NATen, aber ich habe leider keinen Schimmer, wie das realisiert wird.
Hat vielleicht irgend jemand gute Hinweise oder idealerweise sogar eine Anleitung dazu? Ich verwende übrigens auf meiner Seite einen Cisco 2811 Router und da der Kunde an T-Systems angebunden ist nehme ich mal an, dass dort ebenfalls Cisco im Spiel ist.
Vielen Dank im Voraus für jede Unterstützung und beste Grüße
Andreas
ich habe gerade die undankbare Aufgabe bekommen, unser Supportnetz (10.10.10.0/24) mit einem Kundennetz (10.0.0.0/8) per Site-to-Site VPN verbinden zu dürfen.
Die Verbindung zwischen den Peers läuft erwartungsgemäß einwandfrei und genauso erwartungsgemäß kollidieren die beiden Netze beim Routing miteinander. Der Kunde weicht keinen Millimeter von seiner Maximalforderung ab, auf seiner Seite das 10er Netz als Class-A Netz zu betreiben. Genauso wenig kann ich bei mehr als hundert Site-to-Site Verbindungen unser Netz umstellen.
Ich habe gehört, dass es wohl möglich ist, den Traffic im Tunnel zu NATen, aber ich habe leider keinen Schimmer, wie das realisiert wird.
Hat vielleicht irgend jemand gute Hinweise oder idealerweise sogar eine Anleitung dazu? Ich verwende übrigens auf meiner Seite einen Cisco 2811 Router und da der Kunde an T-Systems angebunden ist nehme ich mal an, dass dort ebenfalls Cisco im Spiel ist.
Vielen Dank im Voraus für jede Unterstützung und beste Grüße
Andreas
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: 114955
Url: https://administrator.de/contentid/114955
Printed on: April 19, 2024 at 19:04 o'clock
6 Comments
Latest comment
Keine leichte Aufgabe, denn wie du weisst ist das generell nicht möglich, da du dann auf beiden Seiten gleiche IP Netze hast und damit ist ein Routing bzw. eine VPN Infrastruktur völlig unmöglich !
Deine einzige Chance ist in der Tat NAT. Da auf beiden Seiten ein Cisco ist ist es dennoch mit einigen Klimmzügen lösbar !
Das Binding den VPN Tunnels darf beidseitig aber natürlich niemals auf Interfaces mit 10er Adressen geschehen sondern muss auf nicht 10er Adressen passieren !
Das kann z.B. beim Cisco über eine Loopback Adresse geschehen.
Beim Cisco sieht das so aus:
!
interface Tunnel0
description VPN Tunnel
no ip address
ip mtu 1440
tunnel source Ethernet0
tunnel destination 172.16.1.254
crypto map vpnacl
!
So sähe die Tunnel Definition aus beim Cisco ! Die Tunnel source darf dann nur auf ein Interface zeigen wo keine 10er Adresse konfiguriert ist, ebenso muss die Destination eine nicht 10er Adresse sein.
Z.B. Loopback Source 172.16.10.254, und Destination wie oben die Loopback Adresse 172.16.1.254.
Mit ip nat inside und ip nat outside konfigurierst du nun NAT auf diesem Tunnel.
Dein Kunde schickt dann alles auf Ziel IP Adressen im 172.16.10.0er Netz was bei dir die Loopback Adresse ist.
Du musst hier nun ein statisches NAT auf die Source Adresse einrichten, das dein Netzwerk niemals die Ursprungsadresse des Kunden sieht und durch NAT denkt die Pakete kommen aus dem 172.16.1.0er Netz. Entsprechend muss das analog auf der anderen Seite passieren das die durchs NAT dort denken alle Pakete von dir kommen vom 172.16.10.0er Netz !
Der Nachteil ist das du für jede einzelne Verbindung einen statischen NAT Eintrag beidseitig machen musst aber nur damit ist das Problem überhaupt lösbar. Eine andere Chance hast du gar nicht außer natürlich der Anpassung der IP Adressierung.
Als weitere Schwierigkeit kommt noch dazu das der Kunde einen Cisco von T-Systems im Einsatz hat auf dem T-Systems ihm natürlich keinerlei Zugriff gewährt.
Dort ist also diese komplexe NAT Konfig keinesfalls umzusetzen, sondern nur über eine zusätzlichen (Cisco) Router den der Kunde dann selber betreiben muss.
Ein erheblicher Mehraufwand der aber das Problem letztlich lösen kann.
Eine etwas intelligentere IP Adresstruktur auf Seiten deines Kunden hätte das Problem aber gar nicht erst aufkommen lassen !!
Deine einzige Chance ist in der Tat NAT. Da auf beiden Seiten ein Cisco ist ist es dennoch mit einigen Klimmzügen lösbar !
Das Binding den VPN Tunnels darf beidseitig aber natürlich niemals auf Interfaces mit 10er Adressen geschehen sondern muss auf nicht 10er Adressen passieren !
Das kann z.B. beim Cisco über eine Loopback Adresse geschehen.
Beim Cisco sieht das so aus:
!
interface Tunnel0
description VPN Tunnel
no ip address
ip mtu 1440
tunnel source Ethernet0
tunnel destination 172.16.1.254
crypto map vpnacl
!
So sähe die Tunnel Definition aus beim Cisco ! Die Tunnel source darf dann nur auf ein Interface zeigen wo keine 10er Adresse konfiguriert ist, ebenso muss die Destination eine nicht 10er Adresse sein.
Z.B. Loopback Source 172.16.10.254, und Destination wie oben die Loopback Adresse 172.16.1.254.
Mit ip nat inside und ip nat outside konfigurierst du nun NAT auf diesem Tunnel.
Dein Kunde schickt dann alles auf Ziel IP Adressen im 172.16.10.0er Netz was bei dir die Loopback Adresse ist.
Du musst hier nun ein statisches NAT auf die Source Adresse einrichten, das dein Netzwerk niemals die Ursprungsadresse des Kunden sieht und durch NAT denkt die Pakete kommen aus dem 172.16.1.0er Netz. Entsprechend muss das analog auf der anderen Seite passieren das die durchs NAT dort denken alle Pakete von dir kommen vom 172.16.10.0er Netz !
Der Nachteil ist das du für jede einzelne Verbindung einen statischen NAT Eintrag beidseitig machen musst aber nur damit ist das Problem überhaupt lösbar. Eine andere Chance hast du gar nicht außer natürlich der Anpassung der IP Adressierung.
Als weitere Schwierigkeit kommt noch dazu das der Kunde einen Cisco von T-Systems im Einsatz hat auf dem T-Systems ihm natürlich keinerlei Zugriff gewährt.
Dort ist also diese komplexe NAT Konfig keinesfalls umzusetzen, sondern nur über eine zusätzlichen (Cisco) Router den der Kunde dann selber betreiben muss.
Ein erheblicher Mehraufwand der aber das Problem letztlich lösen kann.
Eine etwas intelligentere IP Adresstruktur auf Seiten deines Kunden hätte das Problem aber gar nicht erst aufkommen lassen !!
Hallo Andreas,
ich denke auch, das du bei den genannten Gegebenheiten nur mit NAT weiterkommst! aqui hat ja bereits ausführlich aufgezeigt, wie zwei Cisco-Endgeräte zu konfigurieren wären.
Weißt du, ob die beim Kunden verwendeten IP-Adressen bzw. die, die für dich eine Rolle spielen auf einen Bereich begrenzt werden können? Wenn ja, könntest du mit Subneting bzw. CIDR ansetzen. D.h. du greifst den zu berücksichtigenden Bereich heraus und bildest daraus ein kleineres IP-Netz (z.B. 10.1.0.0/16 oder 10.0.1.0/24 oder ...). Diese Unterteilung erfolgt "virtuell" - auf Seite des Kunden muss nichts geändert werden! Der auf deiner Seite verwendete IP-Adressbereich 10.10.10.0/24 muss bei den Überlegungen ausgespart werden - beim Kunden verwendete IP-Adressen aus diesem IP-Adressbereich kannst du nicht erreichen.
Anschließend konfigurierst du auf deiner Seite den VPN-Tunnel (Netzwerk der Gegenstelle ist hier der "herausgegriffene", neue IP-Adressbereich). Hier kommt NAT ins Spiel! D.h. der Traffic, der über diesen VPN-Tunnel läuft, muss "genatet" werden. Wie dies bei Cisco aussieht... siehe oben! In der Firma arbeite ich mit SonicWALLs. Hier sähe das NAT so aus: alles was aus 10.10.10.0/24 kommt und über VPN gehen soll, setze auf "deine" öffentl. IP-Adresse (WAN) um und sende es erst anschließend über den VPN-Tunnel.
Das hier NAT verwendet wird, ist bei der Konfiguration des VPN-Tunnels auf der Gegenseite zu berücksichtigen: als entferntes Netzwerk (remote network) ist nicht 10.10.10.0/24 einzutragen, sondern eben "deine" öffentl. IP-Adresse.
Entscheidens ist, ob das Zusammenspiel von VPN und NAT bei deiner Konstellation funktioniert. Sind die zwei VPN-Endgeräte von verschiedenen Herstellern kann das klappen, muss aber nicht!
Grüße!
ich denke auch, das du bei den genannten Gegebenheiten nur mit NAT weiterkommst! aqui hat ja bereits ausführlich aufgezeigt, wie zwei Cisco-Endgeräte zu konfigurieren wären.
Weißt du, ob die beim Kunden verwendeten IP-Adressen bzw. die, die für dich eine Rolle spielen auf einen Bereich begrenzt werden können? Wenn ja, könntest du mit Subneting bzw. CIDR ansetzen. D.h. du greifst den zu berücksichtigenden Bereich heraus und bildest daraus ein kleineres IP-Netz (z.B. 10.1.0.0/16 oder 10.0.1.0/24 oder ...). Diese Unterteilung erfolgt "virtuell" - auf Seite des Kunden muss nichts geändert werden! Der auf deiner Seite verwendete IP-Adressbereich 10.10.10.0/24 muss bei den Überlegungen ausgespart werden - beim Kunden verwendete IP-Adressen aus diesem IP-Adressbereich kannst du nicht erreichen.
Anschließend konfigurierst du auf deiner Seite den VPN-Tunnel (Netzwerk der Gegenstelle ist hier der "herausgegriffene", neue IP-Adressbereich). Hier kommt NAT ins Spiel! D.h. der Traffic, der über diesen VPN-Tunnel läuft, muss "genatet" werden. Wie dies bei Cisco aussieht... siehe oben! In der Firma arbeite ich mit SonicWALLs. Hier sähe das NAT so aus: alles was aus 10.10.10.0/24 kommt und über VPN gehen soll, setze auf "deine" öffentl. IP-Adresse (WAN) um und sende es erst anschließend über den VPN-Tunnel.
Das hier NAT verwendet wird, ist bei der Konfiguration des VPN-Tunnels auf der Gegenseite zu berücksichtigen: als entferntes Netzwerk (remote network) ist nicht 10.10.10.0/24 einzutragen, sondern eben "deine" öffentl. IP-Adresse.
Entscheidens ist, ob das Zusammenspiel von VPN und NAT bei deiner Konstellation funktioniert. Sind die zwei VPN-Endgeräte von verschiedenen Herstellern kann das klappen, muss aber nicht!
Grüße!
Hallo etschbi,
vielen Dank für die freundliche Hilfestellung.
Der Kunde ist leider gar nicht kompromissbereit, was die EInschränkung des 10er Netzes auf seiner Seite anbelangt. Deshalb werde ich jetzt mal die NAT-Konfiguration in Angriff nehmen. Zum Glück muss nicht auf beiden Seiten genattet werden, sondern nur auf meiner Seite, denn ich kann eine Host-Route auf den zu erreichenden Rechner im Zielnetz legen, die sich nicht mit dem Class-C Ausschnitt in unserem Netz "beißt". Somit bin ich wenigstens nicht auf aktiven Support durch T-Systems angewiesen
Gruß
Andreas
vielen Dank für die freundliche Hilfestellung.
Der Kunde ist leider gar nicht kompromissbereit, was die EInschränkung des 10er Netzes auf seiner Seite anbelangt. Deshalb werde ich jetzt mal die NAT-Konfiguration in Angriff nehmen. Zum Glück muss nicht auf beiden Seiten genattet werden, sondern nur auf meiner Seite, denn ich kann eine Host-Route auf den zu erreichenden Rechner im Zielnetz legen, die sich nicht mit dem Class-C Ausschnitt in unserem Netz "beißt". Somit bin ich wenigstens nicht auf aktiven Support durch T-Systems angewiesen
Gruß
Andreas
Da bist du im Irrtum ! Du musst natürlich auch deine IP Adressen NATen ! Denn es darf keine deiner 10er Adressen beim Kunden auftauchen und vice versa keine der Kunden IPs bei dir....
Ggf. hast du aber dennoch recht, wenn du das bidirektional NATen nur auf einer Seite sowohl inbound als auch outbound machen kannst.
Ob das aber auf einem VPN Tunnelinterface klappt solltest du mal testen.
Ein Feedback hier wäre mal ganz spannend, zumal es ja auch das Problem des T-System Routers umgeht... !
Ggf. hast du aber dennoch recht, wenn du das bidirektional NATen nur auf einer Seite sowohl inbound als auch outbound machen kannst.
Ob das aber auf einem VPN Tunnelinterface klappt solltest du mal testen.
Ein Feedback hier wäre mal ganz spannend, zumal es ja auch das Problem des T-System Routers umgeht... !
Hallo Andreas,
hast du Erfolge erzielen können? Würde mich auch interessieren!
MfG,
hast du Erfolge erzielen können? Würde mich auch interessieren!
MfG,
