Cisco IPSec Site-to-Site-VPN. Datenverkehr zulassen, wenn VPN nicht verfügbar ist


9

Ein bisschen Konfigurationsplanung für Gürtel und Hosenträger.

Hintergrund:

Wir haben eine erfolgreiche Site-to-Site-VPN-Verbindung zu unserem Remote-Rechenzentrum.

Das entfernte "geschützte" Netzwerk ist auch der IP-Netzwerkbereich, der über die Firewall als mit dem Internet verbundene Endpunkte geöffnet wird.

Also : Wir verwenden das VPN, um auf nicht öffentliche Endpunkte zugreifen zu können.

Problemstellung :

Wenn die VPN-Verbindung unterbrochen ist, beendet der ASA den Datenverkehr, obwohl die Internetendpunkte weiterhin über die Remote-Firewall verfügbar sein sollten.

Frage :

Wie kann ich das VPN so konfigurieren, dass der Datenverkehr als regulärer ausgehender Datenverkehr weitergeleitet wird, wenn das VPN nicht verfügbar ist?

Hier sind die relevanten Segmente der Konfiguration.

crypto map vpn-crypto-map 20 match address remdc-vpn-acl
crypto map vpn-crypto-map 20 set peer a.b.c.d 
crypto map vpn-crypto-map 20 set transform-set remdc-ipsec-proposal-set
crypto map vpn-crypto-map interface outside

Die ACL für den übereinstimmenden Datenverkehr ist sehr primitiv: Sie gibt die beiden privaten und Remote-Netzwerke an, die als Netzwerkobjekte ausgedrückt werden.

access-list remdc-vpn-acl extended permit ip object <private> object <remote> log 

Und ein primitives Diagramm.

                                     INTERNET
                                                x
                                                x
REM DC 203.000.113.000/24                      xx                       HQ 192.168.001.000/24
                                               x
           +---------------+                  x               +-----------+
           | REMOTE DC     |                 xx               |           |
           | ASA           e               xxx                | ASA 5505  |
+----------+               |              xx                  |           +-----------------+
   ^       |               e<-------------------------------------+       |
   |       |               |              xxxx                |           |
   |       |               e                 xxxx             |     ~     |
   |       |               |                    xx            |     |     |
   |       |               |                     xx           +----vpn----+
   |       |               |                      x                 |
   \-------vpn-------------vpn--------------------------------------/
           |               |                   xxx
           +---------------+                  xx
                                           xxx
                                          xx
                                       xxxx
    e = public Internet                x
        server endpoint

Vielen Dank

rauben

Update 01

Eine genauere ACL wurde in den Kommentaren unten besprochen (mit Dank)

Ich kann mir zwei ACLS vorstellen. (A) das ALL dem Remote-Netz erlaubt und dann Endpunkte verweigert, die bereits über das Internet verfügbar sind. und (B) die nur das Management / die Instrumentierung nach Bedarf öffnet.

Das Problem mit (B) ist, dass das Ausdrücken von Endpunkten wie WMI und Windows RPC unpraktisch ist, ohne das Standard-Server-Conf zu optimieren.

Vielleicht ist (A) der beste Ansatz, der eine Umkehrung der Remote- Firewall- Konfiguration darstellt.

Update 02

Mike hat darum gebeten, mehr von der ios-Konfiguration des ASA zu sehen.

Was folgt, ist für die HQ ASA, die sich am HQ-Standort befindet. Der Remote-DC wird vom Rechenzentrumsanbieter gesteuert, daher kann ich nicht genau sagen, wie das konfiguriert werden kann.

Nun, es gibt nicht viel zu zeigen: Es gibt eine Standardroute zum Internet-Gateway und keine anderen spezifischen Routen.

route outside 0.0.0.0 0.0.0.0 HQInetGateway 1

Schnittstellen sind sehr einfach. Nur grundlegende IPv4-Konfiguration und vlans zum Aufteilen der Gruppe in 1 externe Schnittstelle und 1 interne Schnittstelle.

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.30.2.5 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 194.28.139.162 255.255.255.0
!

Prost, Rob


Mir ist nicht klar, ob Sie bei ausgefallenem VPN auf private Adressen zugreifen möchten.
Radtrentasei

Können Sie ein Diagramm der Konnektivität bereitstellen? Die von uns angebotene Lösung hängt wahrscheinlich vom spezifischen Layout und der Ausstattung ab.
Brett Lykins

Das sogenannte "geschützte" Netzwerk ist eigentlich ein öffentliches IP-Segment. Es ist Firewall, aber nicht NAT-ed. Idealerweise sollten die öffentlichen Endpunkte weiterhin verfügbar sein, wenn das VPN nicht verfügbar ist.
Rob Shepherd

1
Eine genauere ACL ist wahrscheinlich die beste Wahl. Sie könnten auch einen GRE-Tunnel innerhalb des VPN erstellen, dies würde jedoch mehr Hardware erfordern. Wenn Sie weitere Details zur ACL veröffentlichen, können wir Ihnen helfen. Vielleicht die ersten beiden Ziffern ändern, um die Unschuldigen zu schützen?
Ron Trunk

1
Rob, könnten Sie uns mehr über die Konfiguration des ASA geben? Insbesondere Routing / Schnittstellenkonfigurationen wären nützlich, um zu sehen
Mike Pennington

Antworten:


2

Ich bin jetzt der Meinung, dass dies nicht praktisch ist; Zumindest in unserem speziellen Szenario.

Das Schema wird weiter durch die Tatsache kompliziert, dass der Verkehr "zum Tunneln" von der ACL zwischen HQ und RemoteDC ausgewählt wird (und wir es so kompliziert machen können, wie wir wollen), aber auf dem umgekehrten "Pfad" (sozusagen) der Der VPN-Konzentrator am Remote-Ende wählt das gesamte HQ-Netzwerk als geschütztes Netzwerk aus.

Das Ergebnis ist, dass diese nicht ausgeglichen sind und es scheint, dass die Vorwärts- und Rückwärts-Xlates nicht übereinstimmen. Ähnlich wie bei Vorwärts- und Rückwärtsrouten, bei denen der Datenverkehr fehlschlägt, weil NAT irgendwann im Spiel ist.

Im Wesentlichen - dies wird als "zu hohes technisches Risiko" verschrottet und erfordert viel mehr Bewertung und möglicherweise mehr Kontrolle über das entfernte Ende, bevor es zu einer Lösung wird.

Vielen Dank an alle, die darüber nachgedacht haben.


Vielen Dank für Ihr Follow-up ... Ich hoffte, dass wir eine Lösung mit einem dynamischen Routing-Protokoll über IPSec finden würden. obwohl ich gestehen muss, dass ich mit dieser Lösung keine Erfahrungen aus erster Hand habe.
Mike Pennington

0

Wenn Sie einen Router auf der Innenseite jedes ASA haben oder installieren können, können Sie einen verschlüsselten GRE-Tunnel erstellen und entweder Routing oder eine schwebende statische Aufladung verwenden, um einen Fehler im Internet zu verursachen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.