VPN от Cisco PIX до Juniper Netscreen на основе политик не проходит этап 2 Предложение

Я следовал инструкциям по настройке VPN между устройством netscreen и Cisco PIX в соответствии с указаниями Cisco [netscreen to PIX VPN] http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801c4445.shtml статья.

Разница лишь в том, что я использую PIX 6.3(5) и Juniper Netscreen 6.1.0r2.0 (Firewall+VPN). Я точно следовал обеим конфигурациям, и когда я пытаюсь подключиться, Juniper возвращается с:

2010-02-21 12:54:28  information IKE: Removed Phase 2 SAs after receiving a notification message. 
2010-02-21 12:54:28  information IKE pix_public_IP: Received a notification message for DOI 1 14 NO-PROPOSAL-CHOSEN. 
2010-02-21 12:54:28  information IKE pix_public_IP Phase 2: Initiated negotiations.

На Netscreen я создал предложение фазы 2 под названием ToCorpOffice, используя DH Group#2, 3DES-CBC и SHA-1, и при настройке AutoKey IKE я выбрал ToCorpOffice и удалил все другие преобразования. Я считаю, что я настроил то же самое на PIX с:

sysopt connection permit-ipsec
crypto ipsec transform-set mytrans esp-3des esp-sha-hmac
crypto map mymap 10 ipsec-isakmp
crypto map mymap 10 match address nonat
crypto map mymap 10 set pfs group2
crypto map mymap 10 set peer netscreen_public_ip
crypto map mymap 10 set transform-set mytrans
crypto map mymap interface outside

Сохранено и перезагружено, так вот информация о криптомарте: PIX-FW1# show crypto map

Crypto Map: "mymap" interfaces: { outside }

Crypto Map "mymap" 10 ipsec-isakmp
    Peer = netscreen_public_ip
    access-list nonat; 1 elements
    access-list nonat line 1 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 (hitcnt=0)
    Current peer: netscreen_public_ip
    Security association lifetime: 4608000 kilobytes/28800 seconds
    PFS (Y/N): Y
    DH group:  group2
    Transform sets={ mytrans, }
PIX-FW1#

Любая идея, почему я получаю ошибку NO-PROPOSAL-CHOSEN?

Источник

6 ответов

Добавьте локальные и удаленные подсети в идентификатор прокси-сервера - это заставит его работать

Источник

В большинстве случаев я видел эту проблему, это было связано с несовпадением домена шифрования (ID прокси). Поскольку вы используете VPN на основе политик на стороне Juniper, а не VPN на основе маршрутов, вы увидите, что сторона Juniper попытается настроить IPSec SA, соответствующие политикам. Например, если ваша политика Juniper выглядит следующим образом:

set policy id 50 from "Untrust" to "Trust" "ext-192.168.1.50" "int-192.168.2.50" "HTTP"...

Конфигурация VPN на основе политики будет ожидать, что ASA попытается установить IPSec SA между хостами, который переходит с 192.168.1.50 на 192.168.2.50, в то время как ASA пытается установить туннель с 192.168.2.0/24. до 192.168.1.0/24.

Я не могу точно знать, что это так в вашей конфигурации, потому что вы не публикуете политики со стороны Juniper, но эту проблему я чаще всего встречал с симптомами, похожими на ваши. Самым простым решением было бы изменить список доступа на ASA, чтобы он соответствовал политикам на брандмауэре Juniper (с оговоркой, что он все еще должен быть "разрешить ip" вместо указания протоколов L4+, поскольку вы указываете только прокси-сервер). Я БЫ).

Источник

Мой поставщик хотел видеть весь мой трафик с одного IP-адреса. Я установил политику, основанную на маршруте, с Tunnel.1 и Loop.1, создал цикл с /26, чтобы исходящий NAT IP находился в диапазоне (они указали адрес, который хотели видеть мой трафик, и это был широковещательный IP). для всех диапазонов, пока я не сделал это /26). Я сделал свой DIP на туннельном интерфейсе (они указали 1 IP, поэтому DIP был от 172.28.1.95 до.95) и создал политики, чтобы сопоставить их Cisco Crypto_Map с исходной трансляцией моего исходящего DIP.

Сложность заключалась в том, что мне пришлось создавать отдельные фазы II (IKE AutoKey VPN) и использовать идентификаторы прокси для соответствия их crypto_map. Когда я сделал первый этап II, этот работал. Как только я сделал больше одного, это потерпело неудачу.

Чтобы это исправить, мне нужно было адресовать адрес GW к маршрутам по адресам, к которым я подключался (вместо того, чтобы просто сказать, что надо отключить интерфейс tunnel.1, пришлось сделать это плюс IP GW), а затем к интерфейсу tunnel.1 должен был сделать Next Hop Tunnel Binding. Я не думаю, что вы даже увидите это в качестве опции, пока не создадите вторую фазу II и не свяжете ее с интерфейсом туннеля, потому что, если у вас есть только один туннель, он вам просто не нужен. Таким образом, для каждой записи в домене шифрования (crypto_map) (и в этом отношении для каждой фазы II, которую я должен был настроить) я создал запись NHTB, у которой был IP-адрес удаленной стороны (снова из их crypto_map) с соответствующей записью VPN. Фаза II VPN.

Источник

Я получил эту ошибку после того, как у моего Netscreen был неправильный локальный комбинированный IP-адрес / маска сети.

Источник

Не только ответ Тома О'Коннора не полезен, это - ФУД. Устройства Juniper похожи на любое другое устройство, если вы настраиваете устройство, которое правильно реализует спецификацию IPSec, единственная трудность возникает из-за незнания того, как это сделать на этом устройстве.

Попробуйте статью в Juniper KB об устранении неполадок VPN. Это может быть более полезным.

http://kb.juniper.net/index?page=content&id=KB9221

Как выглядит ваша конфигурация SSG?

Источник

Общеизвестно, что Juniper VPN трудно убедить в общении с другими устройствами. IME, они действительно счастливы, когда общаются с другими устройствами Juniper.

Я подозреваю, что это может быть что-то похожее.

Источник
Другие вопросы по тегам