Налаштування VPN від сайту до сайту Cisco ASA

Нещодавно ми замінили міжнародні MPLS новими ASA 5510 та VPN-сайтами. Однак, коли ми розгорнули це, ми зіткнулися з проблемою, коли в кожному віддаленому місці є 2 провайдери для надмірності, але при включенні VPN на обох інтерфейсах він замикається між двома, а тунель піднімається вгору і вниз, коли тунель розривається і переміщується між Інтернет-провайдери. Cisco працює над цим вже 8 місяців, і ми все ще не маємо стабільних тунелів з декількома провайдерами.

Віддалений офіс:

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

Центральний офіс:

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

Отже, що я виявив - це те, що коли ISAKMP увімкнено для обох зовнішніх інтерфейсів (віддалений офіс), і обидва IP-адреси налаштовані як однорангові (центральний офіс), VPN успішно з'являється на обох інтерфейсах, але в якийсь момент почне перемикатися між IP-адресами. Це вірно з моніторингом за угодою SLA або без нього, тому навіть якщо маршрути статичні, поведінка все ще виникає.

Будь-яке розуміння цінується.

Я просто мігрую сайти подалі від VPN, заснованих на політиці, саме з цієї причини. На основі політик VPN занадто непередбачувані, коли мова йде про поведінку в режимі відмови. Я набагато віддаю перевагу маршрутизованим тунелям IPsec, як точка-точка, так і DMVPN. На жаль, наскільки мені відомо, платформа ASA все ще не підтримує маршрутизовані тунелі.

Я рекомендую використовувати рішення DMVPN для підключення віддалених сайтів через тунелі L2L (Lan-to-Lan) IPSec між ASA. Рішення DMVPN набагато простіше, чистіше, а також дозволить спілкуватися з розмовною розмовою.

Може бути:

CSCub92666

ASA: Старі з'єднання руйнують тунель IPSEC vpn при переключенні

Ознака: в IPsec тунель vpn вийшов з ладу через конфігурацію на ASA, відмова від первинного до резервного посилання працює. Але після другого відмови від резервного копіювання до первинного каналу vpn тунель починає махати через кілька хвилин і залишається нестабільним. Поведінка спостерігається через те, що старе з'єднання, що залишилося, все ще вказує на резервне копіювання.

Я згоден з вищезазначеними твердженнями. Перейдіть на простий IPSEC на основі VTI або в якості альтернативи DMVPN. Просто пам’ятайте, щоб запускати різні екземпляри прокотолів маршрутизації в тунелях і без них. Так, вам доведеться замінити ASA на ISR.

Чи повертаються обидва провайдери до одного головного офісу ASA чи двох? Якщо двом, мені важко бачити (як мінімум, доступний конфігуратор), як ця поведінка могла відбуватися, але якщо це одна і та сама ASA (або та сама пара), це могло бути пов'язане.

Як подальше питання щодо цього питання, я працював з Cisco TAC над цим питанням вже більше року. Вони нарешті визначили, що це помилка з тим, як платформа ASA обробляє з'єднання. по суті, не було очищення з'єднань з одного інтерфейсу, коли він перемістив тунель на інший інтерфейс, і він вийшов з-під контролю, оскільки він почав бачити записи в таблиці з'єднань з обох інтерфейсів.

Я розгорнув IOS версії 8.4.7 на брандмауері з двома провайдерами, і, здається, він веде себе належним чином. Відмова відбувається, коли основний інтерфейс виходить з ладу, а потім переміщується назад, коли цей інтерфейс повертається І залишається на цьому інтерфейсі. Ми побачимо.