Przełączanie awaryjne VPN między lokalizacjami Cisco ASA

Niedawno zastąpiliśmy międzynarodowy MPLS nowymi ASA 5510 i VPNami typu site-to-site. Jednak po wdrożeniu tego napotkaliśmy problem polegający na tym, że każda zdalna lokalizacja ma 2 dostawców usług internetowych w celu zapewnienia nadmiarowości, ale podczas włączania VPN na obu interfejsach klapy między nimi a tunelem są w górę i w dół, gdy tunel się rozrywa i przenosi między Dostawcy usług internetowych. Cisco pracuje nad tym od 8 miesięcy i nadal nie mamy stabilnych tuneli z wieloma dostawcami usług internetowych.

Zdalne biuro:

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

Centrala:

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 *****

Odkryłem więc, że kiedy ISAKMP jest włączony na obu zewnętrznych interfejsach (zdalne biuro) i oba adresy IP są skonfigurowane jako równorzędne (centralne biuro), VPN działa pomyślnie na obu interfejsach, ale w pewnym momencie zacznie trzepotać między IP. Jest to prawdą z monitorowaniem SLA lub bez niego, więc nawet jeśli wszystkie trasy są statyczne, zachowanie nadal występuje.

Doceniamy każdy wgląd.

Właśnie z tego powodu migruję witryny z VPN opartych na zasadach. Sieci VPN oparte na zasadach są zbyt nieprzewidywalne, jeśli chodzi o zachowanie awaryjne. Zdecydowanie wolę oparte na trasach tunele IPsec, zarówno punkt-punkt, jak i DMVPN. Niestety, o ile wiem, platforma ASA nadal nie obsługuje tuneli opartych na trasach.

Polecam korzystanie z rozwiązania DMVPN do łączenia zdalnych stron za pośrednictwem tuneli IPSec L2L (Lan-to-Lan) między ASA. Rozwiązanie DMVPN jest znacznie łatwiejsze, czystsze i pozwala również na komunikację w mowie.

Możliwe:

CSCub92666

ASA: Stare połączenia burzą tunel VPN IPSEC przy przełączaniu

Objaw: W konfiguracji IPsec tunelu IPsec do przełączania awaryjnego w ASA przełączanie awaryjne z połączenia podstawowego na zapasowe działa. Ale po drugim przełączeniu awaryjnym z kopii zapasowej do podstawowego łącza tunel VPN zaczyna trzepotać za kilka minut i pozostaje niestabilny. Zachowanie to jest obserwowane ze względu na stare resztkowe połączenie nadal wskazujące na kopię zapasową isp.

Zgadzam się z powyższymi stwierdzeniami. Wybierz prosty IPSEC oparty na VTI lub alternatywnie DMVPN. Pamiętaj tylko, aby uruchamiać różne instancje procotol routingu w tunelach i bez nich. Tak, musisz wymienić ASA na ISR.

Czy obaj dostawcy usług internetowych wracają do jednej lub dwóch ASA w centrali? Jeśli dwa trudno mi zobaczyć (przy przynajmniej dostępnej konfiguracji), w jaki sposób takie zachowanie może wystąpić, ale jeśli jest to ta sama ASA (lub ta sama para), może być powiązana.

Jako kontynuacja tego pytania współpracuję z Cisco TAC nad tym zagadnieniem od ponad roku. W końcu ustalili, że jest to błąd związany ze sposobem, w jaki platforma ASA obsługuje połączenia. zasadniczo nie usuwano połączeń z jednego interfejsu, gdy przeniósł tunel do drugiego interfejsu i wymknąłby się spod kontroli, gdy zaczął widzieć wpisy w tabeli połączeń w obu interfejsach.

Zainstalowałem IOS w wersji 8.4.7 na zaporze ogniowej z dwoma dostawcami usług internetowych i wygląda na to, że działa poprawnie. Przełączanie awaryjne ma miejsce, gdy główny interfejs ulegnie awarii, a następnie cofnie się, gdy interfejs powróci ORAZ pozostanie w tym interfejsie. Zobaczymy.