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.
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło
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.
źródło
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.
źródło