IpSec туннели на три офиса глюки...
-
PF стоит 2.2.4...
Можно конечно обновить его, но это не быстро.
В сторону OPENVPN смотрел изначально, но меня убедили что IpSec для туннелей как раз и предназначен.
система без связки B-C плюс мобильные клиенты (на IpSec тоже) работает уже несколько лет. По этому и связку B-C поднял на IpSecПопробую OpenVPN поднять между B-C. я так понимаю что работе связок A-B и A-C настроенных на ipSec это все равно никак не помешает.
По крайней мере посмотрю будет это работать или нет.
Спасибо -
@konstanti said in IpSec туннели на три офиса глюки...:
Если у Вас PF 2.4.4 - то можно попробовать настроить VTI туннель
Почитал про VTI, действительно интересно, спасибо.
Rather than managing IPsec Phase 2 entries, routes must be managed instead
Дилетантский вопрос - Phase 2 получается вообще не нужна?@haliava said in IpSec туннели на три офиса глюки...:
я так понимаю что работе связок A-B и A-C настроенных на ipSec это все равно никак не помешает.
Не должно. Вынужденно использую ipSec + OpenVPN уже 3 года, друг другу они никак не мешают.
-
@pigbrother said in IpSec туннели на три офиса глюки...:
Не должно. Вынужденно использую ipSec + OpenVPN уже 3 года, друг другу они никак не мешают.
А почему вынуждено? От чего так пришлось сделать?
-
@haliava said in IpSec туннели на три офиса глюки...:
почему вынуждено
3 года назад появилась необходимость подключить наш центральный офис к чужому центральному. На их стороне кроме IPSEC не поддерживалось ничего из стандартного.
-
@pigbrother said in IpSec туннели на три офиса глюки...:
3 года назад появилась необходимость подключить наш центральный офис к чужому центральному. На их стороне кроме IPSEC не поддерживалось ничего из стандартного.
Понял - ситуация обратная моей была....
Может стоит все 3 офиса на OpenVPN перевести? -
@haliava said in IpSec туннели на три офиса глюки...:
Может стоит все 3 офиса на OpenVPN перевести?
Тут популярно мнение, что OpenVPN менее производителен.
Я его не разделяю. В плане управления маршрутизацией\разрешениеями мне OpenVPN подходит\нравится больше. Возможно - из-за ограниченного опыта с IpSec .
Ну и правила:
Не трожь систему, которая работает
никто не отменял.
-
@pigbrother Это вечная тема для споров )))
Как про курицу или яйцо
P.S>
У vti есть фаза два )
иначе , как бы трафик , который маршрутизируется, шифровался бы -
@pigbrother said in IpSec туннели на три офиса глюки...:
Не трожь систему, которая работает
никто не отменял.Да просто иметь две разные системы имея возможность привести все к единому стандарту наверное тоже не лучший вариант...
Так или иначе сначала все равно просто попробую OpenVPN поднять между B-C...
Я уже по машинам пошел искать глюки - может дело и не в IpSec-е совсем.....
Ладно бы совсем не работало - это было бы проще, а то никакой закономерности выловить не могу... -
@haliava Согласен , не лучший
Работает IPSEC и пусть работает
Не забываем еще и про мобильных клиентов , которым надо будет программки ставить для OPENVPN и настраивать все это
По теме, логи есть на хостах ?
Можете поподробнее описать проблему ? -
@konstanti said in IpSec туннели на три офиса глюки...:
По теме, логи есть на хостах ?
Можете поподробнее описать проблему ?Штатные логи подняты
В логах самого IpSec вот такого вида все:
Oct 25 17:37:56 charon: 07[IKE] <con2|53> sending DPD request
Oct 25 17:37:56 charon: 07[IKE] <con2|53> sending DPD request
Oct 25 17:37:56 charon: 07[ENC] <con2|53> generating INFORMATIONAL request 215 [ ]
Oct 25 17:37:56 charon: 07[NET] <con2|53> sending packet: from 31.173.93.241[500] to 77.247.191.2[500] (76 bytes)
Oct 25 17:37:56 charon: 07[NET] <con2|54> received packet: from 77.247.191.2[500] to 31.173.93.241[500] (76 bytes)
Oct 25 17:37:56 charon: 07[ENC] <con2|54> parsed INFORMATIONAL response 214 [ ]
Oct 25 17:37:56 charon: 07[NET] <con2|53> received packet: from 77.247.191.2[500] to 31.173.93.241[500] (76 bytes)
Oct 25 17:37:56 charon: 07[ENC] <con2|53> parsed INFORMATIONAL response 215 [ ]
Oct 25 17:38:06 charon: 09[NET] <con2|53> received packet: from 77.247.191.2[500] to 31.173.93.241[500] (76 bytes)
Oct 25 17:38:06 charon: 09[ENC] <con2|53> parsed INFORMATIONAL request 34 [ ]
Oct 25 17:38:06 charon: 09[ENC] <con2|53> generating INFORMATIONAL response 34 [ ]
Oct 25 17:38:06 charon: 09[NET] <con2|53> sending packet: from 31.173.93.241[500] to 77.247.191.2[500] (76 bytes)
Oct 25 17:38:06 charon: 07[NET] <con2|54> received packet: from 77.247.191.2[500] to 31.173.93.241[500] (76 bytes)77.247.191.2 и 31.173.93.241 - адреса моих офисов...
Подробности какие сообщить?
Я сравнивал существующие тоннели A-B B A-C c B-C - по принципу "найди 10 отличий" - все кроме внешних адресов и локалок одинаковое. Логи правда только IpSec-а смотрел...
Надо бы по другим еще полазить..... -
@haliava Это логи ipsec , тут у Вас , судя по Вашим словам, все хорошо
Понять бы в какой момент у Вас проблемы начинаются
И именно посмотреть логи на хостах/серверах
Мб на IPSEC зря грешите -
@konstanti said in IpSec туннели на три офиса глюки...:
Мб на IPSEC зря грешите
И такая мысль вертится в голове.
Сегодня утром на серверах с двух сторон логи почистил - сейчас вечером все разбегутся - буду в них криминал смотреть.
Туннель продолжил глючить с утра - где-то в обед я его отключил - посмотрю что есть в логах... -
@haliava Заодно , можно глянуть лог General PF, туда тоже частенько ошибки сыпятся. И Gateways так же посмотрите , там ошибки по сети вылезают .
Я в проблемы сети слабо верю , но для самоуспокоения проверить надо -
Хорошо - спасибо
-
@Haliava , Если найдете причину проблемы, плз - отпишитесь, плз.
Сам сталкивался с подобным, правда не на pfSense. Там все было выражено резко. Обе фазы IPSEC поднимались, пинги между сетями ходили ,но SMB\RDP сессии не работали категорически (вернее работали 1 раз из 100).
Конфигурация полностью повторяла работающую в других местах с тем же оборудованием как в центре, так и в точке подключения, отличался только провайдер. Его поддержка ничем не помогла, попытки изменить MSS, MTU и т.д тоже.
Причина так и осталась загадкой. Объект надо было утром сдавать, пришлось от IPSEC отказаться. -
@pigbrother Доброго дня
Кстати , насчет MSS интересная мысль , у меня везде вот так
-
День добрый.
У меня Enable MSS clamping on VPN traffic везде отключен.
Стоит попробовать включить? -
@haliava Попробовать можно в варианте B-C. Всяко может быть в Вашем случае.
Вдруг сработает. -
А значение стоит оставить по умолчанию или его можно как-то рассчитать?
-
@haliava Есть куча инфы в инете по расчету MTU-MSS для IPSEC
Cisco рекомендует в большинстве случаев 1400 - 1360
Даже если посмотреть документацию на Strongswan , то можно увидеть вот такую строчку
Т е они рекомендуют MSS ставить 1360 тоже
Но , опять же , повторюсь , не факт что У Вас проблема в этом