Problem mit Fernzugriff, festem L2L und dynamischem L2L IPSEC, die auf ASA 5540 8.2 zusammenarbeiten

Ich habe ein Problem mit einer Mischung aus Fernzugriffs-, L2L- und dynamischen L2L-Tunneln auf einem ASA5540 mit 8.2

Hier ist ein Ausschnitt der relevanten Konfiguration: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10
crypto dynamic-map outside-crypto-dynamic-map 10 set transform-set ESP-3DES-MD5
crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 201 match address outside-crypto-map-201
crypto map outside-crypto-map 201 set peer X.X.X.X
crypto map outside-crypto-map 201 set transform-set ESP-3DES-MD5
crypto map outside-crypto-map 202 match address outside-crypto-map-202
crypto map outside-crypto-map 202 set peer Y.Y.Y.Y
crypto map outside-crypto-map 202 set transform-set ESP-AES256-SHA
crypto map outside-crypto-map 65535 ipsec-isakmp dynamic outside-crypto-dynamic-map
crypto map outside-crypto-map interface outside

Ich habe eine Reihe von Remote-Standorten, die dynamische IPs verwenden. Die LAN-Subnetze für diese befinden sich in einer ACL "extern-crypto-dynamic-map-10".

Diese stimmen gut überein, basierend auf dieser Linie: -

crypto dynamic-map outside-crypto-dynamic-map 10 match address outside-crypto-dynamic-map-10

Ich habe andere "statische" L2L-Tunnel, die gemäß 201 und 202 in der obigen Konfiguration einwandfrei funktionieren.

Bei Benutzern mit Remotezugriff (Cisco VPN-Client) wird keine Verbindung hergestellt, sofern ich nicht die folgende Leitung habe: -

crypto dynamic-map outside-crypto-dynamic-map 20 set transform-set ESP-3DES-MD5

Wenn ich versuche, dieser Sequenz eine "Match Address" -Anweisung hinzuzufügen (wie unten), funktioniert der Remotezugriff nicht mehr (wobei "vpc-client-subnet" eine ACL ist, die das Subnetz aus dem für die Remotezugriffsclients verwendeten IP-Pool enthält). da es keine passende lokale / entfernte finden kann.

crypto dynamic-map outside-crypto-dynamic-map 20 match address vpc-client-subnet

Das Problem ist, dass ich eine Reihe von L2L-Endpunkten habe (die ich nicht mehr verbinden möchte, aber keine Kontrolle darüber habe), die noch (auf der Remote-Seite) mit dem PSK konfiguriert sind, das von den dynamischen L2L-Peers verwendet wird. Ich habe ihre LAN-Subnetze aus "extern-crypto-dynamic-map-10" entfernt (da ich nicht mehr möchte, dass sie verbunden sind), damit sie nicht mehr mit der dynamischen Karte seq 10 übereinstimmen, aber sie sind immer noch in der Lage Phase 2 gegen "Outside-Crypto-Dynamic-Map 20" erfolgreich abzuschließen, und es scheint, als ob dieses Ende nur das akzeptiert, was die Fernbedienung als lokale / Fernbedienung für die SA vorschlägt.

Ich bin nicht in der Lage, die PSK zu ändern. Ich kann der "external-crypto-dynamic-map 20" keine "Übereinstimmungsadresse" hinzufügen, da dadurch verhindert wird, dass RAS-Clients eine Verbindung herstellen. Wenn dies jedoch nicht der Fall ist, fungiert sie als Sammelbegriff für andere Peers das kennt sonst die PSK.

Idealerweise könnte ich "Übereinstimmungsadresse" zu Sequenz 20 hinzufügen, damit Benutzer mit Fernzugriff mit dieser übereinstimmen, die "alten" Peers nach Sequenz 10 jedoch nicht. Gibt es alternativ eine Möglichkeit, zu verhindern, dass der ASA die Idee der Remote-Peers von local / remote für die SA akzeptiert, wenn sie mit einer Karte abgeglichen wurde, die keine "Match Address" -Anweisung enthält?

BEARBEITEN:

Die entsprechende Tunnelgruppenkonfiguration: -

tunnel-group DefaultL2LGroup ipsec-attributes
 pre-shared-key *****
 peer-id-validate nocheck
 isakmp keepalive threshold 30 retry 5

tunnel-group x.x.x.x type ipsec-l2l
tunnel-group x.x.x.x ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 5

tunnel-group ravpn type remote-access
tunnel-group ravpn general-attributes
 address-pool ip-pool-ravpn
 authentication-server-group Edirectory
 default-group-policy ravpn
tunnel-group ravpn ipsec-attributes
 pre-shared-key *****
 isakmp keepalive threshold 30 retry 2

tunnel-group-map default-group DefaultL2LGroup

Es gibt mehrere Tunnelgruppen für die "statischen" Tunnel (gemäß dem obigen xxxx-Beispiel). Die RAS-Benutzer treffen die Tunnelgruppe "ravpn", und die dynamischen Benutzer stimmen alle mit der "DefaultL2LGroup" überein. Die PSK ist zwischen diesen nicht gleich.

Ich würde vorschlagen, eine zweite RAS-Tunnelgruppe für alle Ihre RAS-Benutzer zu erstellen. Starten Sie die Migration nacheinander. Wenn Sie fertig sind, können Sie die vorhandene Standard-L2L-Gruppe löschen oder die PSK ändern.

Wenn Sie auf Benutzer stoßen, die keine Änderungen vornehmen möchten, können Sie eine bestimmte VPN-Client-Version erzwingen und sie darüber informieren, dass Sie ein umfangreiches Sicherheitsupdate durchführen.

Normalerweise benötigen Ihre Remote-VPN-Benutzer nur ein paar Zeilen unter der dynamischen Krypto-Map, damit sie eine ordnungsgemäße Verbindung herstellen können. Etwas wie das:

Crypto Dynamic Map DYN_CRY_MAP 65535 set transform-set ESP-AES-128-SHA

Kryptokarte OUTSIDE_map 65535 ipsec-isakmp dynamic DYN_CRY_MAP

Dies setzt voraus, dass Sie den entsprechenden passenden Transformationssatz bereits angegeben haben.

Die VPN-Subnetze Ihres Remotebenutzers müssen nicht in der Kryptozuordnung angegeben werden, da es sich um dynamische Endpunkte handelt. Der ASA weiß das und passt die Kryptotabellen entsprechend an. Ihre dynamischen L2L-Endpunkte müssen auch nicht unter der Krypto-Map angegeben werden und funktionieren auf die gleiche Weise. Ein "Feature" ist auch, dass die letzte der beiden obigen Zeilen ganz am Ende Ihrer Kryptokarte angewendet werden muss. Sie haben es bereits dort, wollten es Sie aber nur wissen lassen.

Über diese Leitung kann Phase 1 von einem dynamischen L2L-Endpunkt aus eine Verbindung herstellen:

Tunnelgruppe DefaultL2LGroup IPPS-Attribute

 Geteilter Schlüssel *****

 peer-id-validate nocheck

 isakmp keepalive Schwelle 30 Wiederholung 5

Phase 2 wird von Ihren Kryptokarteneinträgen behandelt.

Ich befürchte, dass der einfachste und effektivste Weg, dies zu tun, darin besteht, die PSK in der Tunnelgruppe DefaultL2LGroup und dann auf allen Geräten zu ändern, die noch verbunden werden sollen. Da es sich um dynamische Endpunkte handelt, können Sie auf der externen Schnittstelle nicht wirklich nach IP filtern, und Sie haben keine Kontrolle darüber, ob sie einen Tunnel einrichten, wenn sie die PSK kennen.

Wenn Sie Fragen haben, zögern Sie bitte nicht zu fragen.

Ian

@aleks - Wenn Sie wissen, welche L2L-Geräte Sie nicht mehr zulassen möchten und deren private IP-Bereiche Sie kennen, können Sie diese privaten IP-Adressen in Ihrer eingehenden ACL (die auf die externe Schnittstelle Ihres ASA angewendet wird) nicht einfach ablehnen. Dies verhindert möglicherweise nicht die Einrichtung von Phase 2, lässt jedoch den Datenverkehr mit Sicherheit nicht zu. Nur ein Gedanke (ich bin auf diese Frage gestoßen, als ich nach einem anderen Thema gegoogelt habe).