Вопросы Теги

ЯЩИК ДЛЯ ПРОБНОЙ МОНЕТЫ Cisco к Juniper Netscreen основанная на политике VPN приводит Предложение по Фазе 2 к сбою

cpp -dM предварительно обрабатывает исходный или заголовочный файл и печатает каждый #define то, что это находит. Это более устойчиво, чем захват через /usr/include/errno.h, так как это получит каждый файл это /usr/include/errno.h включает.

Объединение cpp-dM с предложениями других:

function lookuperror
{
    cpp -dM /usr/include/errno.h | grep -w "$@"
    perl -MPOSIX -e 'print "Description:".strerror($ARGV[0])."\n";' $@
}

Вставьте в .bashrc или поместите его содержание как автономный сценарий оболочки.

3
задан 21 February 2010 в 20:53
6 ответов

Большинство раз я видел эту проблему, это происходило из-за домена шифрования (идентификатор прокси) несоответствие. Поскольку Вы используете основанную на политике VPN на стороне Juniper и не основанную на маршруте VPN, Вы собираетесь видеть, что сторона Juniper пытается создать SAS IPSec, которые соответствуют политикам. Например, если Ваша политика 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 + протоколы, так как Вы указываете просто идентификатор прокси).

1
ответ дан 3 December 2019 в 07:44

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

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

-2
ответ дан 3 December 2019 в 07:44
  • 1
    Да, I' ve, замеченный то же с другими устройствами, но изображенный, так как это было зарегистрировано и Cisco и Juniper, это wouldn' t быть слишком твердым. I' ll продолжают смешивать с предложениями и надо надеяться понимают это если я don' t получают другой ответ здесь, потому что этот клиент, вероятно, won' t утверждают больше аппаратных средств :) –  elint 21 February 2010 в 23:29
  • 2
    Mmm. Это, кажется, один из тех " undocumented" функции, который говорит " наши аппаратные средства только говорят с нашими аппаратными средствами, если Вы хотите к смешиванию и подгонке, забываете it" Извините я couldn' t быть большего количества справки. В прошлом мы просто придерживались единственного поставщика аппаратные средства VPN или использовали OpenVPN повсюду. –  Tom O'Connor 22 February 2010 в 00:55

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

1
ответ дан 3 December 2019 в 07:44

Не только ответ Tom O'Connor, не полезный, это - FUD. Устройства Juniper точно так же, как любое другое устройство при установке устройства, которое реализует спецификацию IPSec правильно, единственная трудность прибывает из не знания, как сделать так на том устройстве.

Попробуйте статью о КБ Juniper при поиске и устранении неисправностей VPNs. Это могло бы быть более полезно.

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

На что похожа Ваша конфигурация SSG?

0
ответ дан 3 December 2019 в 07:44
  • 1
    kb.juniper.net/KB6168 Сводка: Полученный уведомляют сообщение для DOI < 1> < 14> < no_proposal_chosen > проблема или Цель: Среда: * согласование Фазы 1 IKE, успешное * Фаза 2, инициировало согласование перед < NO_PROPOSAL_CHOSEN> обменивайтесь сообщениями появился Признаки & Ошибки: * Полученный уведомляют сообщение для DOI < 1> < 14> < NO_PROPOSAL_CHOSEN> * согласование Фазы 2 IKE приводит Решение к сбою: Если фаза 2 инициировала, и Вы получаете сообщение, это указывает на несоответствие в предложениях между двумя коллегами. Возможности, одна сторона имеет nopfs, в то время как другой стороне включили совершенную прямую секретность. –  Null Route 24 February 2010 в 21:08
  • 2
    It' s не FUD, it' s личный опыт. –  Tom O'Connor 25 February 2010 в 13:21
  • 3
    p1-предложение по иконоскопу набора " ToCorpOffice" group2 esp 3des sha-1 перед долей вторые 3 600 p2-предложений по иконоскопу набора " ToCorpOffice" group2 esp 3des sha-1 вторые 26400 Похожи на обоих, использует группу 2 DH, 3des/sha-1, следовательно мой беспорядок это it' s не работающий. Я согласовываю это it' s пользовательская ошибка " не зная, как сделать так на этом device". I' ve обычно устанавливают site-to-site' s на sonicwalls или можжевельниках в однородных средах. Это - второй juniper-> другая конфигурация VPN I' ve попытался, и когда первый перестал работать, они bouth другой мультитехнический маршрутизатор для их VPN :P –  elint 25 February 2010 в 18:43
  • 4
    mikeyb' s предложение, чтобы позволить войти в систему ЯЩИК ДЛЯ ПРОБНОЙ МОНЕТЫ, кажется, указывает на меня в правильном направлении. Похож на ЯЩИК ДЛЯ ПРОБНОЙ МОНЕТЫ, имеет проблемы конфигурации политики. Я didn' t знают, как получить доступ к журналам, таким образом, я просто шел Juniper' s журнал. Все еще работая над ним, все же. –  elint 25 February 2010 в 20:14

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

0
ответ дан 3 December 2019 в 07:44

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

Хитрая часть была то, что я имел к созданному отдельному II's Фазы (IKE AutoKey VPNs), и используйте идентификатор прокси для соответствия их crypto_map. Когда я сделал первую Фазу II, которая один работала. После того как я сделал более затем один, он перестал работать.

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

1
ответ дан 3 December 2019 в 07:44

Теги

Похожие вопросы