Chuyển đổi dự phòng VPN tại chỗ của Cisco ASA

Gần đây chúng tôi đã thay thế MPLS quốc tế bằng ASA 5510 mới và VPN tại chỗ. Tuy nhiên, khi chúng tôi triển khai điều này, chúng tôi đã gặp phải một vấn đề trong đó mỗi vị trí từ xa có 2 ISP để dự phòng, nhưng khi bật VPN trên cả hai giao diện, nó sẽ bị trượt giữa hai và đường hầm lên xuống khi đường hầm bị phá hủy và di chuyển giữa ISP. Cisco đã làm việc này được 8 tháng và chúng tôi vẫn không có đường hầm ổn định với nhiều ISP.

Văn phòng từ xa:

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

Văn phòng Trung tâm:

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

Vì vậy, những gì tôi đã tìm thấy là khi ISAKMP được bật trên cả hai giao diện bên ngoài (văn phòng từ xa) và cả hai IP được cấu hình như các máy ngang hàng (văn phòng trung tâm), VPN xuất hiện thành công trên cả hai giao diện, nhưng đến một lúc nào đó sẽ bắt đầu vỗ giữa các IP. Điều này đúng với hoặc không có Giám sát SLA, vì vậy ngay cả khi các tuyến đều tĩnh, hành vi vẫn xảy ra.

Bất kỳ cái nhìn sâu sắc được đánh giá cao.

Tôi đã di chuyển các trang web ra khỏi VPN dựa trên chính sách chỉ vì lý do này. VPN dựa trên chính sách quá khó đoán khi có hành vi chuyển đổi dự phòng. Tôi rất thích các đường hầm IPsec dựa trên tuyến đường, hoặc điểm-điểm hoặc DMVPN. Thật không may, theo hiểu biết của tôi, nền tảng ASA vẫn không hỗ trợ các đường hầm dựa trên tuyến đường.

Tôi khuyên bạn nên sử dụng giải pháp DMVPN để kết nối các trang web từ xa qua các đường hầm IPSec L2L (Lan-to-Lan) giữa các ASA. Giải pháp DMVPN dễ dàng hơn, sạch sẽ hơn và cũng sẽ cho phép giao tiếp nói được nói.

Có thể là:

CSCub92666

ASA: Các kết nối cũ phá bỏ đường hầm IPSEC vpn khi chuyển đổi

Triệu chứng: Trong đường hầm IPsec vpn không thành công về cấu hình trên ASA, lỗi từ liên kết chính đến liên kết dự phòng hoạt động. Nhưng sau lần thất bại thứ hai từ bản sao lưu đến đường hầm vpn liên kết chính bắt đầu vỗ trong vài phút và vẫn không ổn định. Hành vi được quan sát vì kết nối còn sót lại cũ vẫn trỏ đến isp dự phòng.

Tôi đồng ý với các tuyên bố trên. Sử dụng IPSEC dựa trên VTI đơn giản hoặc DMVPN thay thế. Chỉ cần nhớ chạy các trường hợp Procotol định tuyến khác nhau trong và không có đường hầm. Vâng, bạn sẽ phải thay thế ASA bằng ISR.

Cả hai ISP sẽ quay trở lại một trụ sở chính ASA hoặc hai? Nếu hai tôi thấy khó thấy (với cấu hình có sẵn ít nhất) thì hành vi này có thể xảy ra như thế nào, nhưng nếu cùng một ASA (hoặc cùng một cặp) thì nó có thể liên quan.

Để theo dõi câu hỏi này, tôi đã làm việc với Cisco TAC về vấn đề này trong hơn một năm. Cuối cùng họ đã xác định rằng đây là một lỗi với cách nền tảng ASA xử lý các kết nối. về cơ bản, nó không xóa các kết nối từ một giao diện khi nó chuyển đường hầm sang giao diện khác và nó sẽ vượt khỏi tầm kiểm soát khi nó bắt đầu thấy các mục trong bảng kết nối ra cả hai giao diện.

Tôi đã triển khai phiên bản IOS 8.4.7 trên tường lửa với hai ISP và nó thực sự có vẻ hoạt động đúng. Chuyển đổi dự phòng đang xảy ra khi giao diện chính bị hỏng, và sau đó di chuyển trở lại khi giao diện đó quay lại VÀ còn lại trên giao diện đó. Chúng ta sẽ thấy.