Cisco ASA-Standort-zu-Standort-VPN-Failover

Wir haben kürzlich internationales MPLS durch neue ASA 5510 und Site-to-Site-VPNs ersetzt. Als wir dies bereitstellten, stießen wir jedoch auf ein Problem, bei dem jeder Remotestandort zwei ISPs für Redundanz hat. Wenn jedoch das VPN auf beiden Schnittstellen aktiviert wird, klappt es zwischen den beiden und dem Tunnel auf und ab, wenn der Tunnel abgerissen und zwischen diesen verschoben wird ISPs. Cisco arbeitet bereits seit 8 Monaten daran, und wir haben immer noch keine stabilen Tunnel mit mehreren ISPs.

Remote-Büro:

access-list RWS_TUNNEL remark Interesting traffic for IND-RWS tunnel
access-list RWS_TUNNEL extended permit ip object-group BNG_tunnel_NETS object-group CORP_tunnel_NETS
crypto map RWS_TUNNEL 1 match address RWS_TUNNEL
crypto map RWS_TUNNEL 1 set peer 216.xxx.102.2 
crypto map RWS_TUNNEL 1 set transform-set IND-RWS
tunnel-group 216.xxx.102.2 type ipsec-l2l
tunnel-group 216.xxx.102.2 ipsec-attributes
 pre-shared-key *****


route outside 0.0.0.0 0.0.0.0 216.xxx.206.1 1 track 2
route outside2 0.0.0.0 0.0.0.0 182.xxx.26.229 100
sla monitor 55
 type echo protocol ipIcmpEcho 63.251.61.142 interface outside
 num-packets 5
 timeout 1000
 frequency 10
sla monitor schedule 55 life forever start-time now
track 2 rtr 55 reachability

Hauptbüro:

access-list BNG_TUNNEL remark Interesting traffic for IND-RWS tunnel
access-list BNG_TUNNEL extended permit ip object-group CORP_tunnel_NETS object-group BNG_tunnel_NETS 

route outside2 0.0.0.0 0.0.0.0 216.xxx.102.1
crypto map BNG_TUNNEL 1 match address BNG_TUNNEL
crypto map BNG_TUNNEL 1 set peer 182.xxx.26.230 216.xxx.206.4
crypto map BNG_TUNNEL 1 set transform-set L2L

tunnel-group 182.xxx.26.230 type ipsec-l2l
tunnel-group 182.xxx.26.230 ipsec-attributes
 pre-shared-key *****
tunnel-group 216.xxx.206.4 type ipsec-l2l
tunnel-group 216.xxx.206.4 ipsec-attributes
 pre-shared-key *****

Was ich gefunden habe, ist, dass, wenn ISAKMP auf beiden externen Schnittstellen (Remote Office) aktiviert ist und beide IPs als Peers (Central Office) konfiguriert sind, das VPN auf beiden Schnittstellen erfolgreich gestartet wird, aber irgendwann zwischen IPs flattert. Dies gilt mit oder ohne SLA-Überwachung. Selbst wenn alle Routen statisch sind, tritt dennoch Verhalten auf.

Jeder Einblick wird geschätzt.

Ich habe Sites aus genau diesem Grund von richtlinienbasierten VPNs weg migriert. Richtlinienbasierte VPNs sind im Hinblick auf das Failover-Verhalten zu unvorhersehbar. Ich bevorzuge routenbasierte IPsec-Tunnel, entweder Punkt-zu-Punkt oder DMVPN. Leider unterstützt die ASA-Plattform meines Wissens immer noch keine routenbasierten Tunnel.

Ich würde die Verwendung einer DMVPN-Lösung empfehlen, um Remotestandorte über L2L-IPSec-Tunnel (Lan-to-Lan) zwischen ASAs zu verbinden. Die DMVPN-Lösung ist viel einfacher, sauberer und ermöglicht auch die Kommunikation von Sprache zu Sprache.

Könnte sein:

CSCub92666

ASA: Alte Verbindungen reißen den IPSEC-VPN-Tunnel bei der Umschaltung ab

Symptom: In der IPsec-VPN-Tunnel-Failover-Konfiguration auf ASA funktioniert das Failover von der primären zur Sicherungsverbindung. Aber nach dem zweiten Failover vom Backup auf den primären Link flattert der VPN-Tunnel in wenigen Minuten und bleibt instabil. Das Verhalten wird beobachtet, weil die alte übrig gebliebene Verbindung immer noch auf Backup-ISP verweist.

Ich stimme den obigen Aussagen zu. Gehen Sie einfach VTI-basierte IPSEC oder alternativ DMVPN. Denken Sie daran, innerhalb und außerhalb der Tunnel verschiedene Routing-Protokollinstanzen auszuführen. Ja, Sie müssen die ASAs durch ISRs ersetzen.

Gehen beide ISPs zurück zu einem oder zwei ASA-Hauptsitzen? Wenn zwei Probleme auftreten, kann ich (zumindest mit der verfügbaren Konfiguration) nicht erkennen, wie dieses Verhalten auftreten kann. Wenn es sich jedoch um dasselbe ASA (oder dasselbe Paar) handelt, kann es verwandt sein.

Als Reaktion auf diese Frage arbeite ich seit über einem Jahr mit Cisco TAC zusammen. Sie haben endlich erkannt, dass dies ein Fehler bei der Art und Weise ist, wie die ASA-Plattform Verbindungen verarbeitet. Im Grunde genommen löschte es keine Verbindungen von einer Schnittstelle, als es den Tunnel auf die andere Schnittstelle verschob, und es kam außer Kontrolle, als es begann, Einträge in der Verbindungstabelle über beide Schnittstellen zu sehen.

Ich habe IOS Version 8.4.7 auf der Firewall mit zwei ISPs bereitgestellt und es scheint sich tatsächlich richtig zu verhalten. Ein Failover findet statt, wenn die primäre Schnittstelle ausfällt und wenn diese Schnittstelle wieder verfügbar ist UND auf dieser Schnittstelle verbleibt. Wir werden sehen.