Недавно мы заменили международный 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 начинает колебаться через несколько минут и остается нестабильным. Поведение наблюдается из-за того, что старое оставшееся соединение все еще указывает на резервный провайдер.
источник
Я согласен с вышеуказанными утверждениями. Перейти простой VTI на основе IPSEC или альтернативно DMVPN. Просто не забывайте запускать разные экземпляры протокола маршрутизации внутри туннелей и без них. Да, вам придется заменить ASA на ISR.
Оба провайдера возвращаются в один головной офис ASA или два? Если два, мне трудно понять (по крайней мере, с доступным конфигом), как это может происходить, но если это тот же ASA (или та же пара), то это может быть связано.
источник
В качестве продолжения этого вопроса я работаю с Центром технической поддержки Cisco более года. Они наконец определили, что это ошибка в способе, которым платформа ASA обрабатывает соединения. по сути, он не очищал соединения от одного интерфейса, когда он перемещал туннель к другому интерфейсу, и он выходил из-под контроля, когда начинал видеть записи в таблице соединений из обоих интерфейсов.
Я развернул IOS версии 8.4.7 на брандмауэре с двумя Интернет-провайдерами, и он действительно работает правильно. Аварийное переключение происходит, когда основной интерфейс выходит из строя, а затем возвращается, когда этот интерфейс возвращается И остается на этом интерфейсе. Посмотрим.
источник