IpSec туннели на три офиса глюки...



  • Есть три офиса
    A - 192.168.10.0/24
    B - 192.168.11.0/24
    C - 192.168.12.0/24

    A соединен IpSec туннелями с B и C
    все прекрасно работает из B и С прекрасно видятся все ресурсы А и наоборот... все правила прописаны...
    Понадобилось настроить видимость между точками B и C
    С точно такими же настройками что были у тоннелей A-B и A-C
    Прокинул IpSec тоннель между B-C, а дальше начались странности
    B и С по прежнему прекрасно работают с А (т.е. A-B и A-C), а вот B-C работает через раз....
    Причем закономерности выявить не могу
    Ping идет между B и C всегда - не прерываясь - разве что иногда время растет,
    а например RDP может отвалиться совсем, а через 2-3 минуты снова заработать
    То же самое с сетевыми ресурсами...
    Во всех трех точках подняты контроллеры домена - они тоже между собой общаются нормально. В логах ничего криминального вроде нет...
    DNS-ы друг о друге знают - имена все ресолвятся верно и всегда...

    Дополнительных маршрутов не прописывал - насколько я понял IpSec должен сам это разруливать.
    Причем в том момент когда связь B-C пропадает ни малейших сбоев в связках A-B и A-C не наблюдается
    Туннели не рвутся ни с одной стороны...

    Разрешал все правилах по IpSec и по Lan на всякий случай - не помогает

    В какую сторону смотреть? Или вообще нельзя так тоннели в кольцо объединять?
    Хотя почему бы и нет........



  • @haliava Доброго дня
    Выскажу предположение , что возможно проблема именно в самом IPSEC в "чистом виде" . Так как его работа не предполагает передачу некоторых видов служебного трафика. Например , широковещательных пакетов
    Но это только гипотеза
    Чтобы ее проверить возможны такие варианты
    1 Если у Вас PF 2.4.4 - то можно попробовать настроить VTI туннель между B и C .
    вот ссылка на настройку
    https://www.netgate.com/docs/pfsense/vpn/ipsec/ipsec-routed.html
    2 настроить , к примеру , GRE OVER IPSEC
    3 настроить OPENVPN туннель

    т е использовать туннели , которые могут маршрутизировать трафик



  • 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 так же посмотрите , там ошибки по сети вылезают .
    Я в проблемы сети слабо верю , но для самоуспокоения проверить надо



  • @konstanti

    Хорошо - спасибо



  • @Haliava , Если найдете причину проблемы, плз - отпишитесь, плз.

    Сам сталкивался с подобным, правда не на pfSense. Там все было выражено резко. Обе фазы IPSEC поднимались, пинги между сетями ходили ,но SMB\RDP сессии не работали категорически (вернее работали 1 раз из 100).
    Конфигурация полностью повторяла работающую в других местах с тем же оборудованием как в центре, так и в точке подключения, отличался только провайдер. Его поддержка ничем не помогла, попытки изменить MSS, MTU и т.д тоже.
    Причина так и осталась загадкой. Объект надо было утром сдавать, пришлось от IPSEC отказаться.



  • @pigbrother Доброго дня
    Кстати , насчет MSS интересная мысль , у меня везде вот так
    0_1540538596095_8326696b-515c-4dbb-a9d8-5392b6dd4d41-image.png



  • @konstanti

    День добрый.

    У меня Enable MSS clamping on VPN traffic везде отключен.
    Стоит попробовать включить?



  • @haliava Попробовать можно в варианте B-C. Всяко может быть в Вашем случае.
    Вдруг сработает.



  • @konstanti

    А значение стоит оставить по умолчанию или его можно как-то рассчитать?



  • @haliava Есть куча инфы в инете по расчету MTU-MSS для IPSEC
    Cisco рекомендует в большинстве случаев 1400 - 1360
    Даже если посмотреть документацию на Strongswan , то можно увидеть вот такую строчку
    0_1540541560314_37d802a2-a377-4b89-b9a1-98c410ccb6aa-image.png

    Т е они рекомендуют MSS ставить 1360 тоже
    Но , опять же , повторюсь , не факт что У Вас проблема в этом



  • @konstanti said in IpSec туннели на три офиса глюки...:

    не факт что У Вас проблема в этом

    Тоже так думаю.

    @konstanti said in IpSec туннели на три офиса глюки...:

    насчет MSS интересная мысль , у меня везде вот так

    Как я выше писал - настройки MSS ничего не дали. И повторю - там были не pfSense.



  • @pigbrother said in IpSec туннели на три офиса глюки...:

    Как я выше писал - настройки MSS ничего не дали. И повторю - там были не pfSense.

    @konstanti said in IpSec туннели на три офиса глюки...:

    Но , опять же , повторюсь , не факт что У Вас проблема в этом

    Это понятно... Но за пробу в глаз вроде не должны дать. :)



  • @haliava В логах PF нет ничего подозрительного , совпадающего по времени с проблемами ? Я имею в виду логи не только ipec



  • @konstanti

    Нет.
    Вот только что повторил ситуацию когда сетевая шара пропала.
    в логах IPSec нет криминала
    Oct 26 08:45:18 charon: 08[ENC] <con4|92> generating INFORMATIONAL request 14 [ ]
    Oct 26 08:45:18 charon: 08[NET] <con4|92> sending packet: from 46.38.33.110[500] to 31.173.93.241[500] (76 bytes)
    Oct 26 08:45:18 charon: 08[NET] <con4|92> received packet: from 31.173.93.241[500] to 46.38.33.110[500] (76 bytes)
    Oct 26 08:45:18 charon: 08[ENC] <con4|92> parsed INFORMATIONAL response 14 [ ]

    46.38.33.110 - это С
    31.173.93.241 - это B
    в General и gateways никаких записей.....

    в Firewall нашел интересную запись
    https://yadi.sk/i/hybfJFF0KTw-lw

    Это на стороне офиса В
    где 192.168.12.7 это откуда обращался со стороны офиса С,
    а 192.168.11.14 это к кому обращался на стороне офиса В

    Сейчас ищу что за порт такой 62084...



  • @haliava said in IpSec туннели на три офиса глюки...:

    Oct 26 08:45:18 charon: 08[ENC] <con4|92> generating INFORMATIONAL request 14 [ ]
    Oct 26 08:45:18 charon: 08[NET] <con4|92> sending packet: from 46.38.33.110[500] to 31.173.93.241[500] (76 bytes)
    Oct 26 08:45:18 charon: 08[NET] <con4|92> received packet: from 31.173.93.241[500] to 46.38.33.110[500] (76 bytes)
    Oct 26 08:45:18 charon: 08[ENC] <con4|92> parsed INFORMATIONAL response 14 [ ]

    Правила на интерфесе lan покажите
    И еще вопрос есть ли Floating правила ?



  • @konstanti said in IpSec туннели на три офиса глюки...:

    Правила на интерфейсе lan покажите
    И еще вопрос есть ли Floating правила ?

    на floating ничего.
    На lan сейчас есть правило из lan все порты на все адреса - для поиска косяков включил...
    https://yadi.sk/i/QbGrN_pRcoLj3w

    Блок по порту 62084 ушел, но косяки не прекратились...



  • @haliava said in IpSec туннели на три офиса глюки...:

    Сейчас ищу что за порт такой 62084...

    Это произвольный исходящий порт ПК 12.7 , иницииируещего SMB-сессию с 11.14 . Номер порта ни о чем не говорит. А вот почему он блокируется - вопрос. Кликните на крестик - получите название сработавшего правила.
    И версия PF у вас явно не из свежих.



  • @pigbrother

    PF 2.2.4. Надо бы обновить...
    Сейчас блока нет этого...



  • @pigbrother said in IpSec туннели на три офиса глюки...:

    И версия PF у вас явно не из свежих.

    Извините за офтопик, но удаленно обновить его можно прямо через web интерфейс?
    Он поднимется потом сразу? Или на место все-таки лучше ехать?



  • @konstanti said in IpSec туннели на три офиса глюки...:

    3 настроить OPENVPN туннель

    Поднял OpenVPN туннель между B-C. вот уже около часа 2 пользователя на нем сидят - пока полет нормальный.
    Заметил только что время пингов между B-C стало меньше. Да и визуально расшаренные ресурсы открываются заметно веселее, и, соответственно, все что в них.
    Странно как-то...

    Сейчас читаю про GRE OVER IPSEC - если уж IpSec использую может еще и его попробовать.



  • @haliava Лучше не стоит . В PF свои нюансы в реализации этой технологии .
    Только если в плане эксперимента и понимания , будет ли работа стабильной
    По поводу скорости , в большинстве случаев моего опыта IPSEC был быстрее OPENVPN. При чем значительно .
    Если обновитесь до 2.4.4 , то лучше попробуйте VTI
    Получается , что я был прав , предположив , что какой-то трафик не заворачивался в туннель . Странно , что при этом A-B и A-C работали без проблем



  • @konstanti said in IpSec туннели на три офиса глюки...:

    Получается , что я был прав , предположив , что какой-то трафик не заворачивался в туннель . Странно , что при этом A-B и A-C работали без проблем

    Очень на это похоже... Но A-B и A-C работают и сейчас без проблем.
    Оставлю наверное пока так - попробую сначала обновить PF до 2.4.4, а потом уже попробую VTI.
    я почитал про него - там получается как раз роуты прописывать можно явно - должно помочь...

    Спасибо



  • @konstanti said in IpSec туннели на три офиса глюки...:

    Получается , что я был прав , предположив , что какой-то трафик не заворачивался в туннель

    А может дело как раз в треугольнике. По сути у пакета из C в В два пути. C-B и C-A-B...
    Да они с разной метрикой, но ХЗ как они разруливаются на PF IpSec...
    надо ради интереса поднять еще один PF и устроить чистую звездочку с центром в А.



  • @haliava Вы же в фазе 2 указываете точно , какой трафик уходит в туннель
    у пакета из C в B один путь ) в туннель
    другого пути нет - это особенность IPSEC .
    ТОчно так же из C в А , не пойдет трафик через B
    Поэтому и не надо настраивать статические маршруты
    Но , по уму , если делать все маршрутизируемым , лучше сделать звездой , тут Вы правы. Только зачем еще один PF ?
    Будет просто из B в C путь через А и наоборот



  • @konstanti said in IpSec туннели на три офиса глюки...:

    Вы же в фазе 2 указываете точно , какой трафик уходит в туннель
    у пакета из C в B один путь ) в туннель
    другого пути нет - это особенность IPSEC .

    Так оно, но у меня почему-то стойкое ощущение что именно маршрут не находится...
    Может я и не прав. Не настаиваю.

    @konstanti said in IpSec туннели на три офиса глюки...:

    Только зачем еще один PF ?

    Сугубо для тестирования - чтобы не по живым пробовать. Люди должны работать...



  • @haliava said in IpSec туннели на три офиса глюки...:

    Извините за офтопик, но удаленно обновить его можно прямо через web интерфейс?

    Можно, но лучше не нужно, тем более с 2.2.4. на 2.4. Может потребоваться несколько промежуточных обновлений. Если у вас 2.2.4 - х86, то 2.4 вам обновлениями не получить, поддержка х86 заканчивается на 2.3.5

    Удаленное администрирование роутера - к дальней дороге (с)😃



  • Доброго.

    @Haliava
    Если есть возможность - переходите на Openvpn. Гораздо гибче в настройках, удобнее в (централизованном) админстрировании (в случае схемы клиент-сервер), клиенты есть даже для "кофеварок".

    Есть куча инфы в инете по расчету MTU-MSS для IPSEC

    Существует простой и эффективный способ вычисления MTU используя ping.
    В Win - ping -l размер-пакета-в-байтах -f -t удаленный-адрес
    Размер пакета в байтах подбираем от обратного (напр., 1500 байт), понижая до того момента, когда появится стабильный пинг без ошибок. Можно и скрипт с циклом перебора написать.

    Метод выручал и оправдывал себя не раз.



  • @werter said in IpSec туннели на три офиса глюки...:

    В Win - ping -l размер-пакета-в-байтах -f -t удаленный-адрес
    Размер пакета в байтах подбираем от обратного (напр., 1500 байт), понижая до того момента, когда появится стабильный пинг без ошибок. Можно и скрипт с циклом перебора написать.
    Метод выручал и оправдывал себя не раз.

    Спасибо - попробую...

    А по поводу перевода всех на OpenVPN - у меня куча клиентов IpSec удаленных на всех серверах...
    Можно конечно, но надо крепко подготовиться.

    Я глянул, у меня в центральном офисе IpSec на PF поднят 8 лет назад, и до недавнего времени всех устраивал. Но вот нашла коса на камень....