VPNs zwischen Standorten mit überlappenden Adressen

Gerade habe ich eine Anfrage bekommen, wie man denn Netze verbinden kann, wenn auf beiden Seiten der gleiche Adress-Bereich verwendet wird. Als Lösung gibt es verschiedene Ansätze:

1. Readressierung

Je nachdem wie gut das Netz gepflegt ist, muss das nicht ein zu großer Aufwand sein. Spätestens jetzt könnte das ein Grund sein, um DHCP und DNS konsequent umzusetzen. Wenn die überlappenden Adress-Bereiche durch einen Firmen-Zusammenschluss zustande gekommen sind, dann wird es wohl hierauf hinauslaufen.

2. Erweiterung des Netzes um IPv6

Wenn man sich noch nicht mit IPv6 beschäftigt hat, wird dies sicher am längsten dauern um implementiert zu werden. Aber dann sollte die Wahrscheinlichkeit für überlappende Netze relativ klein sein.

3. Double-NAT zwischen den Netzen

Hierbei werden die mehrfach verwendeten Netze per NAT verborgen. Je nachdem wie viele Standorte den gleichen Adress-Bereich verwenden, kann die Konfiguration und auch das Management dieser Lösung etwas “eklig” werden. Aber gerade wenn unterschiedliche Firmen verbunden werden sollen, ist dies oft die verwendete Lösung.

Dieser Artikel beschreibt die Konfiguration dieses Ansatzes in Verbindung mit VPN-Tunneln.

Das Ausgangs-Szenario:

An beiden Standorten wird das selbe IP-Netz verwendet. Die Lösung beinhaltet, dass beide Standorte ihre IP-Netze per NAT hinter einem anderen Netz “verbergen”. Dieses neue Netz wird dann verwendet, um auf die Geräte der anderen Seite zuzugreifen.
Um die Kombination von NAT und IPSec zu verstehen, muss man sich einfach bewusst sein, in welcher Reihenfolge im IOS die verschiedenen Funktionen abgearbeitet werden: NAT Order of Operation

Wie man sieht, werden die Daten genatted, bevor sie verschlüsselt werden und auf der anderen Seite entschlüsselt, bevor NAT angewendet wird.

Für jede Seite wird jetzt ein freies Netz gewählt (hier 10.111.111.0/24 und 10.222.222.0/24):

Die Source-Adressen des linken Netzes werden in 10.111.111.x übersetzt, die Source-Adressen des rechten Netzes in 10.222.222.x.

Die (relevante) Konfiguration der zwei Router sieht folgendermaßen aus:

hostname R1
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.2.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
 set peer 192.168.2.2
 set transform-set ESP-AES256-SHA
 match address CRYPTO-TO-SITE-2
!
interface FastEthernet0/0
 description LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
!
interface Serial1/0
 description Connection to Internet
 ip address 192.168.1.2 255.255.255.0
 ip nat outside
 crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
ip nat inside source static network 10.10.10.0 10.111.111.0 /24
!
ip access-list extended CRYPTO-TO-SITE-2
 permit ip 10.111.111.0 0.0.0.255 10.222.222.0 0.0.0.255

hostname R2
!
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
crypto isakmp key Yes,ThisKeyIsNotReallySecret,LongAndRandom address 192.168.1.2
!
crypto ipsec transform-set ESP-AES256-SHA esp-aes 256 esp-sha-hmac
!
crypto map VPN 1 ipsec-isakmp
 set peer 192.168.1.2
 set transform-set ESP-AES256-SHA
 match address CRYPTO-TO-SITE-1
!
interface FastEthernet0/0
 description LAN
 ip address 10.10.10.1 255.255.255.0
 ip nat inside
!
interface Serial1/0
 description Connection to Internet
 ip address 192.168.2.2 255.255.255.0
 ip nat outside
 crypto map VPN
!
ip route 0.0.0.0 0.0.0.0 192.168.2.1
!
ip nat inside source static network 10.10.10.0 10.222.222.0 /24
!
ip access-list extended CRYPTO-TO-SITE-1
 permit ip 10.222.222.0 0.0.0.255 10.111.111.0 0.0.0.255

Wenn aus dem linken Netz das rechte erreicht werden soll, muss natürlich die NAT-Adresse genommen werden. Bei einem Ping vom linken LAN-Interface zum rechten LAN-Interface sieht das dann folgendermaßen aus:

R1#ping 10.222.222.1 source fastEthernet 0/0 rep 1 

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.222.222.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
R1#
*Mar  1 00:49:23.527: ICMP: echo reply rcvd, src 10.222.222.1, dst 10.10.10.1

R2#
*Mar  1 00:49:23.319: ICMP: echo reply sent, src 10.10.10.1, dst 10.111.111.1

Ein entscheidender Nachteil dieser Methode ist, dass diese Adress-Übersetzung immer durchgeführt wird und ein Router mit dieser Konfiguration nicht mehr sinnvoll für andere Verbindungen verwendet werden kann. Diese Translation dürfte eigentlich nur verwendet werden, wenn das gegenüberliegende NAT-Netz angesprochen wird.
Diese Bedingung — die auf der PIX/ASA per Policy-NAT einfach umzusetzen ist — würde auf einem IOS-Router mit einer Route-Map beschrieben werden. Diese Route-Maps können aber leider in einer statischen Translation nicht verwendet werden, wenn ganze Netze übersetzt werden.