отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

L2L-VPN over backup interface

Здравствуйте.

 

Помогите пож-та решить проблему - не устанавливается IPsec L2L-VPN через backup интерфейс на ASA5505.

 

Есть центральный офис с ASA5510. Там надежный интернет, поэтому в единственном числе (один провайдер).

Есть удалённая торговая точка с ASA5505. Там два провайдера, основной - по проводу и 3G-модем - как бэкап.

Между этими ASA настроен IPsec L2L-VPN, кот. отлично работает по основному каналу. А вот при переключении на backup-канал L2L-VPN не поднимается вообще.

 

При этом:

- в центр.офисе настроено:

crypto map outside_cryptomap 1234 match address acl
crypto map outside_cryptomap 1234 set transform-set AES256SHA

crypto map outside_cryptomap 1234 set connection-type originate-only
crypto map outside_cryptomap 1234 set peer 1.1.1.1 2.2.2.2

tunnel-group для 1.1.1.1 и для 2.2.2.2

(1.1.1.1 - статич. WAN-адрес основного канала на удалённой точке)
(2.2.2.2 - статич. WAN-адрес backup канала на удалённой точке)

 

- в удалённой точке:

crypto map outside_cryptomap 1234 match address acl
crypto map outside_cryptomap 1234 set transform-set AES256SHA

crypto map outside_cryptomap 1234 set connection-type answer-only
crypto map outside_cryptomap 1234 set peer 3.3.3.3

crypto map outside_cryptomap interface outside
crypto map outside_cryptomap interface backup

(3.3.3.3 статич. WAN-адрес интернет-канала в центр.офисе)

 

Вроде в конфиге всего хватает, ничего не забыл.
А туннель через backup не устанавливается.

 

Забыл сразу привести логи на что жалуется. Исправляюсь. Это с asa5505 (с удаленной точки):

%ASA-5-713119: Group = 3.3.3.3, IP = 3.3.3.3, PHASE 1 COMPLETED
%ASA-3-713061: Group = 3.3.3.3, IP = 3.3.3.3, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 3.3.3.3/255.255.255.255/0/0 local proxy 2.2.2.2/255.255.255.255/0/0 on interface backup
%ASA-3-713902: Group = 3.3.3.3, IP = 3.3.3.3, QM FSM error (P2 struct &0xcc004390, mess id 0x32cb486)!
%ASA-3-713902: Group = 3.3.3.3, IP = 3.3.3.3, Removing peer from correlator table failed, no match!
%ASA-5-713259: Group = 3.3.3.3, IP = 3.3.3.3, Session is being torn down. Reason: crypto map policy not found
%ASA-4-113019: Group = 3.3.3.3, Username = 3.3.3.3, IP = 3.3.3.3, Session disconnected. Session Type: LAN-to-LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: crypto map policy not found
%ASA-5-713904: IP = 3.3.3.3, Received encrypted packet with no matching SA, dropping

9 ОТВЕТ.

а роутинг в аса5505

а роутинг в аса5505 переключаете на бакап ?

New Member

Да, роутинг нормальным

Да, роутинг нормальным образом переключается. Коннективность до центрального офиса в частности и в интернет в общем - есть.

вам сотовый провайдер выдает

вам сотовый провайдер выдает по 3G статический айпи адрес в интернете ?

 

аса5505 пишет ведь что нет соотвествующего криптомап на второй стороне.

т.е. нужно искать на 5510 ошибку

New Member

Да, по 3G ip-адрес

Да, по 3G ip-адрес статический (в примере 2.2.2.2).

 

Ну вот как нет соотвествующего криптомап на второй стороне?!... Ведь это тот же самый криптомап (номер 1234), что и для основного канала. Ну кроме tunnel-group, которых в ЦО две (на осн. и на backup-каналы).

Cisco Employee

Какая версия? Такой баг когда

Какая версия? Такой баг когда-то был, но он давно исправлен.

Есть ли NAT посередине? На 3G же он наверняка есть? 2.2.2.2 это IP ASA или outside IP в NAT'е?

New Member

Версия 8.4(3) Между outside

Версия 8.4(3)

 

Между outside на 5510 (ЦО) и outside на 5505 (удалённая торг. точка) NATа нет, чистый интернет. На 3G (backup-интерфейс на 5505) назначается IP 10.1.1.2/30. Далее есть ASUS 3G-роутер, на его LAN назначается 10.1.1.1/30 и на WAN этого 3G-роутера мобильным оператором выдаётся статический публичный IP 2.2.2.2.

 

Т.е. трафик с inside, идущий через backup, сначала NATится самой 5505 в адрес интерфейса (10.1.1.2), а затем на 3G-роутере в адрес его WANa (2.2.2.2).

 

Но, у меня есть ровно такая схема там, где провайдер умеет только АДСЛ. Там на outside 5505 назначен 10.1.1.2/30, затем на LANe АДСЛ-роутера 10.1.1.1/30, затем на WANe АДСЛ-роутера внешний публичный IP. И при этом crypto-туннель без проблем встаёт и работает.

Cisco Employee

Не верю, если честно. Та

Не верю, если честно. Та сторона, где originate-only, устанавливает туннель на 2.2.2.2 и согласует защищаемые сети 3.3.3.3/32 - 2.2.2.2/32, как и положено этой фиче (originate-only - answer-only). Не может инициатор предложить 3.3.3.3/32 - 10.1.1.2/32, поскольку не знает, какой реальный адрес спрятан за натом. На реципиенте естественно получается:

 

%ASA-3-713061: Group = 3.3.3.3, IP = 3.3.3.3, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 3.3.3.3/255.255.255.255/0/0 local proxy 2.2.2.2/255.255.255.255/0/0 on interface backup

 

Чтобы это работало надо в crypto ACL вписать:

на answer-only-стороне: permit ip host 2.2.2.2 host 3.3.3.3

на originate-only-стороне: permit ip host 3.3.3.3 host 10.1.1.2

 

Это даже описано:

CSCsi15099    Enhancement: Support originate-only/answer-only with NAT

 

New Member

Про "не верю" - там где у

Про "не верю" - там где у меня АДСЛ там нет двух каналов, только один, типа основной. И, соотв., нет деления на originate-only/answer-only (по дефолу bidirectional). Так вот, блин буду :) всё (crypto-туннель) работает. И ровно такой же NAT, с ровно такими же адресами (10.1.1.2/30 на ASA, 10.1.1.1/30 на АДСЛ-роутере). И ровно также в crypto-ACL нет ни слова про 10.1.1.2.

 

Завтра вечером дополню crypto-ACL, как вы сказали, и расскажу что получилось.

 

Как вы умудрились найти CSCsi15099?
Какая логика построения поисковых слов?
Я когда про originate-only/answer-only, что они вообще требуются, узнал, я подумал, что с ними могут быть разные нюансы и порылся поиском на cisco.com, а потом в гугле, чтоб наверняка. Но никаких интересных статей, типа этой, мне тогда не попалось.

 

По-любому - спасибо.

Cisco Employee

Все правильно :) Без

Все правильно :) Без originate-only / answer-only стороны не согласуют между собой proxy identities /32-/32, поскольку default действительно bidir, поэтому и проблема не возникает.

Вообще originate-only / answer-only пришло на PIX и ASA с платформы VPN3k, как и большая часть кода VPN. Там это был единственный механизм организации отказоустойчивого L2L. А с роутеров пришли статические и динамические crypto maps. Получилось два параллельных, но частично пересекающихся кода. Зачем это все - объяснить легко, если знаешь :) Вот:

Поскольку было это давно, то RRI для статических и динамических crypto maps перенесли с багом: статический RRI-маршрут встает на ASA не в момент соединения, а в момент настройки, если применяются статические crypto maps. Это идиотизм на той стороне, где два внешних интерфейса, поскольку рушит всю схему отказоустойчивости. Можно применять dynamic crypto maps. В этом сл. маршрут на удаленную LAN всплывает в момент установки туннеля. Это хорошо, но динамические map'ы не могут инициировать туннели. Приходится туннель всегда инициировать с той стороны. Например, настраивают IP SLA на устройстве. Но это работает только на роутерах, на ASA - нет, поскольку в IP SLA на ASA нельзя выставить SrcIP в трафике. Приходится пинговалку заряжать на какой-нибудь PC в удаленной LAN, если нужно, чтобы туннель всегда был в UP. Неудобно. А представьте, если защищаемых сетей не одна пара, а 3 слева и 5 справа :) 15 пинговалок?

Поэтому иногда применяют answer-only + originate-only, что есть др. код, который разумнее, но со своими тараканами. Во-первых, "интересный" трафик (ping к примеру) не нужен, чтобы поднять туннель. Он встает сам инициируясь со стороны originate-only и согласует /32-/32 между public IP. Во-вторых, по-моему встают все 15 IPsec SA сразу, если послать 1 пинг по одному из них. Т.е. достаточно одной пинговалки (но она к сожалению нужна). Поэтому, как только все поднялось, TCP/UDP-соединения можно инициировать и с answer-only стороны и по всем 15 SA. RRI-маршрут появляется в момент подключения, поэтому отказоустойчивость работает. Удобно. Но какие-то тараканы были и тут. Не помню.

 

Про баг. Мы в Cisco видим не то, что вы в Bug Toolkit, а чуть больше информации, поэтому и поиск у нас другой ;)

167
Просмотры
10
Полезный материал
9
Ответы
СоздатьДля создания публикации, пожалуйста в систему