Я выполнил инструкции по настройке 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 # 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 # показать криптокарту
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?
Мой поставщик хотел, чтобы весь мой трафик шел с одного IP-адреса. Я настроил политику на основе маршрута с Tunnel.1 и Loop.1, создал цикл с / 26, чтобы исходящий IP-адрес NAT находился в диапазоне (они указали адрес, который они хотели видеть, мой трафик, и это был широковещательный IP-адрес). для всех диапазонов, пока не сделал а / 26). Я сделал свой DIP на туннельном интерфейсе (они указали 1 IP, поэтому DIP был от 172.28.1.95 до 0,95) и создал политики, соответствующие их Cisco Crypto_Map с исходной трансляцией моего исходящего DIP.
Сложная часть заключалась в том, что мне пришлось создать отдельные фазы II (IKE AutoKey VPN) и использовать идентификаторы прокси для сопоставления их crypto_map. Когда я сделал первую фазу II, она сработала. Как только я сделал больше одного, ничего не вышло.
Чтобы исправить это, мне пришлось адресовать GW-адрес маршрута к адресам, к которым я подключаюсь (вместо того, чтобы просто сказать «перейти вниз по интерфейсу tunnel.1, нужно было сделать это плюс IP GW»), а затем на интерфейсе tunnel.1. пришлось выполнять привязку туннеля следующего перехода. Я не думаю, что вы даже увидите это как вариант, пока не создадите вторую фазу II и не привяжете ее к интерфейсу туннеля, потому что, если у вас есть только один туннель, он вам просто не нужен. Итак, для каждой записи в домене шифрования (crypto_map) (и в этом отношении для каждой фазы II, которую я должен был настроить) я создал запись NHTB с IP-адресом удаленной стороны (опять же из их crypto_map) с соответствующей записью VPN. Фаза II VPN.
добавить локальные и удаленные подсети в идентификатор прокси - это заставит его работать
В большинстве случаев я видел эту проблему из-за несоответствия домена шифрования (идентификатора прокси). Поскольку вы используете VPN на основе политик на стороне Juniper, а не VPN на основе маршрутов, вы увидите, как сторона Juniper пытается настроить сопоставления безопасности IPSec, соответствующие политикам. Например, если ваша политика Juniper выглядит так:
set policy id 50 from "Untrust" to "Trust" "ext-192.168.1.50" "int-192.168.2.50" "HTTP"...
Конфигурация VPN на основе политик будет ожидать, что ASA попытается установить SA IPSec между хостами, идущую от 192.168.1.50 до 192.168.2.50, в то время как ASA пытается установить туннель, идущий от 192.168.2.0/24. на 192.168.1.0/24.
Я не могу точно знать, что это так с вашей конфигурацией, потому что вы не публикуете политики со стороны Juniper, но это проблема, которую я чаще всего видел с симптомами, похожими на ваши. Самым простым решением было бы изменить список доступа на ASA в соответствии с политиками брандмауэра Juniper (с оговоркой, что он по-прежнему должен быть «разрешить ip» вместо указания протоколов L4 +, поскольку вы указываете только прокси МНЕ БЫ).
Я получил эту ошибку после того, как мой Netscreen имел неправильную комбинацию локального IP-адреса и сетевой маски.
Не только ответ Тома О'Коннора бесполезен, это FUD. Устройства Juniper похожи на любые другие устройства, если вы настраиваете устройство, которое правильно реализует спецификацию IPSec, единственная трудность заключается в том, что вы не знаете, как это сделать на этом устройстве.
Прочтите статью в базе знаний Juniper по устранению неполадок в VPN. Это может быть более полезно.
http://kb.juniper.net/index?page=content&id=KB9221
Как выглядит ваша конфигурация SSG?
Juniper VPN может быть заведомо трудный убедить поговорить с другими устройствами. IME, они действительно счастливы только при разговоре с другими устройствами Juniper.
Я подозреваю, что это может быть что-то подобное.