Добрый день всем форумчанам ! Спасибо всем кто откликнулся на мой предыдущий вопрос , но вот возник новый связанный с очередной проблемой. Данная ситуация повторяется второй раз , на одном из филиалов . Два месяца назад была подобная ситуация. Сейчас она повторилась . В один прекрасный момент, по непонятным причинам, ни с чем не связанным ( изменения конфигурации не производились ) на DFL-260E (fw 2.40.01.08-17758) перестал подниматься туннель IPSec на сертификатах с центральным офисом, при всем при этом пропал доступ на https на wan интерфейс ( хотя telnet на 443 порт говорит что все нормально, порт доступен) , на lan доступ есть как на https так и на http, на ssh доступ есть как на wan так и на lan . Самое забавное , что если зайти на этот DFL , через другой филиал, то доступ на https присутствует, благодаря этому мне удалось все таки на него попасть и я переключил этот туннель на PSK с обеих сторон - туннель поднялся. Железку меняли на абсолютно аналогичную и fw тоже . Переключаю его на сертификаты (повторюсь 2 недели все работало) - он падает и не поднимается. Отсюда проистекают следующие вопросы : 1. может ли это быть козни провайдера и как его на этом уличить, 2. это проблема прошивки , 3. насколько безопасен ipsec PSK в сравнении с сертификатами (в данном случаи парольная фраза не суть важна, я использую hex key 1024 bit интересует именно безопасность в сравнении с сертификатами ) и имеет ли смысл использовать разные PSK для разных туннелей (доступ к DFL имеет очень ограниченный круг лиц и возможность утечки ключа минимальна) ?
Если кто сталкивался с подобным - помогите с вариантами . Доставать провайдера скорее всего бесполезно. У них как всегда нет проблем.

Не доступа по https: а у Вас там фильтр есть по IP-адресам? Может просто поменялся внешний IP центрального офиса? IPSEC на PSK и сертификатах не сильно отличается, PSK -- это не рабочий ключ, генерация ключей и обмен ими идет в обеих случаях через IKE, так что козни провайдера маловероятны.

Фильтрация естественно есть . Адресация статическая и не меняется ни на стороне филиала ни на стороне центрального офиса. Больше всего в данной ситуации напрягает именно то , что она (ситуация) повторяется с заведомой регулярностью , как только мы пробуем перейти на свой VPN - у нас начинаются проблемы. Просто в начале поста я не написал , что с этим филиалом у нас есть уже полноценный VPN реализуемый провайдером , не буду писать какой он , но очень крупный в рамках России . Но цена вопроса стала сильно возрастать со временем, т.к. это услуга у него лимитируема по объему , а объемы растут. Вот и было принято решение о возможности перехода на свои VPN туннели. В данной ситуации , если мы отказываемся от VPN , теряет деньги сам провайдер за услугу и транзитный провайдер который предоставляет "последнюю милю" и они это прекрасно понимают. Вот у нас и складывается стойкое мнение , что оба провайдера в сговоре. При первом таком случаи , мы были вынуждены откатится на старый канал, но через месяц работа DFL на стороне филиала восстановилась сама по себе , при этом его никто не перегружал, просто в один прекрасный момент все заработало и доступ по https и ipsec на сертификатах. Сейчас мы попробовали еще раз, при этом поменяли DFL на филиале и вот она опять, та же самая проблема. Что про это можно сказать ? Происки провайдера. Но с другого филиала , как ни странно доступ есть по https . Такое подозрение что где то , на транзите , что то делает. Забыл сказать что интернет , как ни странно предостсвляет то же провайдер.

Ну не верю я, что провайдер мог зафильтровать IPSEC на сертификатах, оставив на PSK. Не представляю, как это возможно и главное зачем, на PSK тоже все хорошо и достаточно безопасно, хотел бы все порушить, закрыл бы порт 500 IKE. Это какой-то глюк. Начните с недоступности HTTPS, это проще. Смотрите логи или снифер подключите. И все-таки попробуйте отключить фильтрацию на время, при надежном пароле это не страшно.

Попробовал отключить фильтрацию и проверил из разных месть . Из одного места , страничка открылась как положено, а вот из других : происходит предупреждение о самоподписанном сертификате , после согласия с этим , браузер ничего не может открыть и отваливается по таймауту. В логах абсолютно ничего.

В зависимости от версии браузера и его настроек, кривой сертификат может рассматриваться и как фатальная ошибка. Кроме того, https может быть заблокирован Вашим местным файрволлом/прокси. А сквозь туннель (как я понял, на PSK он работает), веб-морда открывается (конечно, нужно соответственно задать фильтр)?
И еще версия. У Вас там на этом филиале нет ли резервирования каналов, условной маршрутизации и т. п.?

Резервирования нет. Все достаточно тривиально. Браузер здесь не причем . Я проверил и через IE и Chrome. Реакция у всех одинаковая. https через туннель работает, так же как и из локальной сети филиала. Сама непонятка , почему с одного из филиалов(на статическом реальном ip) , я спокойно попадаю на wan https. По поводу "Ну не верю я, что провайдер мог зафильтровать IPSEC на сертификатах, оставив на PSK" , ну не кто же не отменял оборудование СОРМ у провайдера . И как лирическое отступление : почему в FW который идет с завода (для россии) на данных аппаратах , максимальна длина ключа в настройках IKE и IPSEC - всего 56 bit? А про 3DES и AES, Blowfish вообще не упоминается. Я не навязываю свое мнение - это просто как комментарий. Будем ждать, что будет дальше.

Тема 100 раз обсуждалась. Русская прошивка с урезанным шифрованием отвечает российскому законодательству.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

В общем, ставьте прошивку WW 2.40.xx и поднимайте IPSEC с шифрованием AES-256, никакой СОРМ не расшифрует, по крайней мере в реальном времени, так что если Ваша конспирологическая теория верна -- должно работать .

"Тема 100 раз обсуждалась. Русская прошивка с урезанным шифрованием отвечает российскому законодательству." Абсолютно верно, тогда почему такой низкий ключ . Насколько я где то читал, что даже в Америке : 128 bit используется для обмена конфиденциальной информацией , а 256 - гос. тайна.

Это как предположение . Допустим у провайдера стоит такая железка , которая это может делать для DES 56bit , а все что свыше - просто блокирует. Я это к тому , что SSL протокол тоже обменивается с браузером своим сертификатом прежде чем поднять SSL соединение, вот поэтому и эффект, что на установку SSL/https , что на IPSEC на сертификатах одинаковая. По видимому , безопасность основанная на обмене сертификатами все таки работает надежнее , чем PSK . Но опять же я высказываю свое сугубо личное предположение.

Ладно . Если никто не сталкивался с таким . Можно заканчивать это обсуждение. Время покажет "ху-из-ху".