IpSec туннели на три офиса глюки...
-
Хорошо - спасибо
-
@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 тоже
Но , опять же , повторюсь , не факт что У Вас проблема в этом -
@konstanti said in IpSec туннели на три офиса глюки...:
не факт что У Вас проблема в этом
Тоже так думаю.
@konstanti said in IpSec туннели на три офиса глюки...:
насчет MSS интересная мысль , у меня везде вот так
Как я выше писал - настройки MSS ничего не дали. И повторю - там были не pfSense.
-
@pigbrother said in IpSec туннели на три офиса глюки...:
Как я выше писал - настройки MSS ничего не дали. И повторю - там были не pfSense.
@konstanti said in IpSec туннели на три офиса глюки...:
Но , опять же , повторюсь , не факт что У Вас проблема в этом
Это понятно... Но за пробу в глаз вроде не должны дать. :)
-
@haliava В логах PF нет ничего подозрительного , совпадающего по времени с проблемами ? Я имею в виду логи не только ipec
-
Нет.
Вот только что повторил ситуацию когда сетевая шара пропала.
в логах 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 у вас явно не из свежих. -
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 и устроить чистую звездочку с центром в А.