Не идет обратный трафик IPSec…
-
Рад что получилось. Сам возьму на заметку ;D
Похоже рано я порадовался… :(
Подключение происходит НО...
Видимо, после того как время действия правила проходит, подключение рвется...Точнее, рвется через 15-20 секунд после подключения...
Потом через полторы минуты (точнее не засекал) переподключается...
Потом опять через 15-20 секунд, рвется опять... ну и т.д....Сейчас буду копать...
Ещё заметил такую вещь...
Когда я подключаюсь по RDP к удаленному компьютеру (192.168.18.3), если никаких действий в RDP окне
не предпринимать, т.е. мышкой не двигать, окна не открывать и т.д. то подключение не рвется продолжительное время...Как заметил: запустил на удаленной машине системные часы...
Пока я ничего не трогал, секундомер "тикал", как только начинал "елозить" мышкой по удаленному Раб.столу,
секундомер, через 15 сек., умирал... А через 90 сек. оживал...Кстати, настройка параметра "Firewall Optimization Options" в "System: Advanced: Firewall and NAT", никакого эффекта
не дает... :( -
1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
2. На интерфейсе VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.
Какие сообщения IPSec?
Покажите конфирурацию файрвола.
А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола? -
1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
2. На интерфейсе VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.Конфигурация правил firewall'а указана выше… Там ничего не менялось...
IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.
С провайдерами всё впорядке… и с IPSec'ом и с UDP тоже всё впорядке... к тому же, были бы проблемы с провайдерами и хождением UDP туннель бы не поднимался, и я бы здесь другие вопросы задавал...
К тому же, на том же FreeBSD сервере, который участвует в связке с pfSense'ом, поднят основной IPSec туннель только уже между двумя FreeBSD (моим домашнем шлюзом и основным шлюзом конторы, на котором поднято 12 IPSec туннелей) с, соответствующим образом, настроенным ipfw... никаких проблем... туннель между двумя подсетями 192.168.5.0/28 и подсетью 192.168.10.0/24, работает исправно... все пакеты ходят туда и обратно без проблем...
Какие сообщения IPSec?
Никаких… У IPSec всё чисто... и вообще, при чем здесь IPSec?...
Два сервака устанавливают подключение меж собой?... Устанавливают...
Трафик внутри туннеля ходит?... Ходит... (см. выше: ICMP ходит в обе стороны без проблем...)
IPSec не валится... это проверено... при "вылете" RDP, ping на тот же хост не прерывается...Покажите конфирурацию файрвола.
Конфигурация правил firewall'а указана выше… Там ничего не менялось...
А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола?
если бы rdp рвал бы подключения он бы вылетал сам с ошибкой… а так, нет... не вылетает...
-
@ Lazy caT
Не оно ли ?
https://redmine.pfsense.org/issues/1841
Martin Saini wrote:
Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?
I managed to get ours working by adding a 'floating' rule in the web interface. We have an allow all rule already on the GRE interface, but the state tracking seemed broken on this, I found a hint somewhere saying to add an allow all 'floating' rule, with interface set to the GRE interface, and direction set to any. Also, note that both the rule on the GRE interface, and the floating rule have advanced option 'State Type' set to 'none'.
looking at the generated pf rules, the following two rules result from this:
pass quick on gre0 all no state label "USER_RULE: Allow all traffic over xxxx"
pass in quick on gre0 all no state allow-opts label "USER_RULE: Allow all internal xxxx traffic"The first rule us the floating rule, it seems to be the one that makes it work. So I guess there's something funny about it that make the direction (in) bit on the second rule be insufficient.
Hope this helps
-
Тогда попробуйте объяснить самому себе почему в логах файрвола появляются записи с действием block.
Тут всё нормально… фактически, в логах firewall'а записи о блокировках не появляется... :)
Уже не появляются... Когда я создал динамическое правило...
Pass IPv4 * * * * * * none TCP flags: Any flags.Но, вот тут есть одно НО…
На сколько я осведомлен в работе firewall'ов, у каждого динамического правила есть так называемый lifetime...
Так вот, когда этот lifetime "оттикает", правило удаляется из таблицы динамических правил... и... происходит то
что происходит... Т.е. "вешается" RDP, до реконнекта (по моему, у winsock подключений дефолтный
timeout около 60 или 90 сек.?) и создания нового правила после реконнекта...И к тому же, создание постоянного, идентичного динамическому, правила в разделе IPSec, эффекта, к сожалению, никакого не даёт. Это уже проверено...
Во, а может Вы попробуете мне объяснить, по сути проблемы?
Как, исходя из написанного мною выше, в данном топике, как сделать так чтобы не RDP не "вешался"?Спасибо.
-
@ Lazy caT
Не оно ли ?
https://redmine.pfsense.org/issues/1841
Martin Saini wrote:
Hi! Have setuped the same config - same issue here :( soo is there any "manual" workaround to that?
I managed to get ours working by adding a 'floating' rule in the web interface. We have an allow all rule already on the GRE interface, but the state tracking seemed broken on this, I found a hint somewhere saying to add an allow all 'floating' rule, with interface set to the GRE interface, and direction set to any. Also, note that both the rule on the GRE interface, and the floating rule have advanced option 'State Type' set to 'none'.
looking at the generated pf rules, the following two rules result from this:
pass quick on gre0 all no state label "USER_RULE: Allow all traffic over xxxx"
pass in quick on gre0 all no state allow-opts label "USER_RULE: Allow all internal xxxx traffic"The first rule us the floating rule, it seems to be the one that makes it work. So I guess there's something funny about it that make the direction (in) bit on the second rule be insufficient.
Hope this helps
Во, ещё раз, спасибо… :)
Scenario 2 очень похоже на мой случай... :) Сейчас буду читать-разбираться... -
Pass IPv4 * * * * * * none TCP flags: Any flags.
Внимательнее! Должно быть TCP flags: none
-
Pass IPv4 * * * * * * none TCP flags: Any flags.
Внимательнее! Должно быть TCP flags: none
Неа, вот тут не соглашусь… :)
В моём случае, работает динамическое правило с установленными TCP флагами…
Если "флаги" в none правило не срабатывает… Проверял...
У меня же блокируются исходящие TCP SYN/ACK... Поэтому, если флаги убрать, траффик под правило
подпадать не будет ни разу... -
И так, подытожу свои разбирательства со всем тем, что было описано выше…
Для корректной работы MS RDP, и не только RDP (а всего что связывается с блокировкой возвращающегося TCP, с флагами SYN/ACK), необходимо добавить "Floating" "Firewall:Rules"
Firewall rule
-
Action: Pass
-
Interface: IPSec
-
Direction: any
-
TCP/IP Version: IPv4
-
Protocol: TCP
-
Source: any
-
Destination: any
-
Destination port range: any
Advanced features
-
TCP flags: Any flags
-
State Type: none
Это финальный вариант, который был "подсмотрен" в посте от werter, вот эта выдержка:
…and the floating rule have advanced option 'State Type' set to 'none'…
На данный момент, RDP работает, пока не "вешается", уже как с полчаса…
Слежу далее за работой... :)Огромное спасибо всем за советы и предложения...
Отдельное СПАСИБО тов. werter, за конструктивные предложения… :) -
-
Еще раз - пожалуйста.
P.s. И таки да , именно в 'State Type' необходим 'none' . Невнимательно глянул, пардон.
