Не идет обратный трафик IPSec…

Lazy caT

Спасибо за совет… :)

Не работает... :(
@werter:

https://forum.pfsense.org/index.php?topic=58943.0
Попробуйте добавить разрерающее правило во Floating rules

Добавил в "Firewall:Rules" -> "Floating" правило:

Pass IPv4 TCP 	VLAN_18_IF net 	3389 (MS RDP) 	* 	* 	* 	none

всё равно, блокируется все исходящие MS:RDP Proto TCP:SA…

@werter:

Go to the webinterface of your pfSense box

Go to System and then to Advanced in the top menu
Click on the Firewall / NAT tab
Change the setting of Firewall Optimization Options to conservative

Это, к сожалению, тоже не помогает… :(

Lazy caT

СТОП…

ЗАРАБОТАЛО... :D

Изменил в "Firewall:Rules" -> "Floating" правило:

Pass IPv4 TCP 	VLAN_18_IF net 	3389 (MS RDP) 	* 	* 	* 	none

добавил ещё TCP flags: Any flags. и ЗАРАБОТАЛО….

Спасибо, werter, за наводку... ОГРОМНОЕ СПАСИБО...

Вот тут, прошу прощения, ошибочка...
Правило такое стало:

Pass IPv4	*	*	*	* 	* 	* 	none

и ещё TCP flags: Any flags.

werter

Рад что получилось. Сам возьму на заметку ;D

Lazy caT

@werter:

Рад что получилось. Сам возьму на заметку ;D

Похоже рано я порадовался… :(

Подключение происходит НО...
Видимо, после того как время действия правила проходит, подключение рвется...

Точнее, рвется через 15-20 секунд после подключения...
Потом через полторы минуты (точнее не засекал) переподключается...
Потом опять через 15-20 секунд, рвется опять... ну и т.д....

Сейчас буду копать...

Ещё заметил такую вещь...

Когда я подключаюсь по RDP к удаленному компьютеру (192.168.18.3), если никаких действий в RDP окне
не предпринимать, т.е. мышкой не двигать, окна не открывать и т.д. то подключение не рвется продолжительное время...

Как заметил: запустил на удаленной машине системные часы...
Пока я ничего не трогал, секундомер "тикал", как только начинал "елозить" мышкой по удаленному Раб.столу,
секундомер, через 15 сек., умирал... А через 90 сек. оживал...

Кстати, настройка параметра "Firewall Optimization Options" в "System: Advanced: Firewall and NAT", никакого эффекта
не дает... :(

SysR

1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
2. На интерфейсе VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.

IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.

Какие сообщения IPSec?
Покажите конфирурацию файрвола.
А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола?

Lazy caT

@SysR:

1, На интерфейсе IPsec разрешите прохождения трафика по все протоколам и направлениям.
2. На интерфейсе VLAN_18_IF в самом верху создайте правило разрешающие прохождение между офисами в обе стороны.

Конфигурация правил firewall'а указана выше… Там ничего не менялось...

@SysR:

IPSec работает поверх протокола UDP интернет-провайдеры на него иногда "забивают", возможно есть смысл позвонить в поддержку. Если качество интернета неудовлетворительное то ВЭБ будет работать но ВПН соеденится уже не сможет.

С провайдерами всё впорядке… и с IPSec'ом и с UDP тоже всё впорядке... к тому же, были бы проблемы с провайдерами и хождением UDP туннель бы не поднимался, и я бы здесь другие вопросы задавал...

К тому же, на том же FreeBSD сервере, который участвует в связке с pfSense'ом, поднят основной IPSec туннель только уже между двумя FreeBSD (моим домашнем шлюзом и основным шлюзом конторы, на котором поднято 12 IPSec туннелей) с, соответствующим образом, настроенным ipfw... никаких проблем... туннель между двумя подсетями 192.168.5.0/28 и подсетью 192.168.10.0/24, работает исправно... все пакеты ходят туда и обратно без проблем...

@SysR:

Какие сообщения IPSec?

Никаких… У IPSec всё чисто... и вообще, при чем здесь IPSec?...
Два сервака устанавливают подключение меж собой?... Устанавливают...
Трафик внутри туннеля ходит?... Ходит... (см. выше: ICMP ходит в обе стороны без проблем...)
IPSec не валится... это проверено... при "вылете" RDP, ping на тот же хост не прерывается...

@SysR:

Покажите конфирурацию файрвола.

Конфигурация правил firewall'а указана выше… Там ничего не менялось...

@SysR:

А это часом не РДП рвет подключение? Нет ли в журналах сервера сообщения об ошибке протокола?

если бы rdp рвал бы подключения он бы вылетал сам с ошибкой… а так, нет... не вылетает...

werter

@ 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

Lazy caT

@SysR:

Тогда попробуйте объяснить самому себе почему в логах файрвола появляются записи с действием block.

Тут всё нормально… фактически, в логах firewall'а записи о блокировках не появляется... :)

Уже не появляются... Когда я создал динамическое правило...


Pass IPv4	*	*	*	* 	* 	* 	none  TCP flags: Any flags.

Но, вот тут есть одно НО…

На сколько я осведомлен в работе firewall'ов, у каждого динамического правила есть так называемый lifetime...
Так вот, когда этот lifetime "оттикает", правило удаляется из таблицы динамических правил... и... происходит то
что происходит... Т.е. "вешается" RDP, до реконнекта (по моему, у winsock подключений дефолтный
timeout около 60 или 90 сек.?) и создания нового правила после реконнекта...

И к тому же, создание постоянного, идентичного динамическому, правила в разделе IPSec, эффекта, к сожалению, никакого не даёт. Это уже проверено...

Во, а может Вы попробуете мне объяснить, по сути проблемы?
Как, исходя из написанного мною выше, в данном топике, как сделать так чтобы не RDP не "вешался"?

Спасибо.

Lazy caT

@werter:

@ 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 очень похоже на мой случай... :) Сейчас буду читать-разбираться...

werter

Pass IPv4 * * * * * * none TCP flags: Any flags.

Внимательнее! Должно быть TCP flags: none

Lazy caT

@werter:

Pass IPv4 * * * * * * none TCP flags: Any flags.

Внимательнее! Должно быть TCP flags: none

Неа, вот тут не соглашусь… :)

В моём случае, работает динамическое правило с установленными TCP флагами…
Если "флаги" в none правило не срабатывает… Проверял...
У меня же блокируются исходящие TCP SYN/ACK... Поэтому, если флаги убрать, траффик под правило
подпадать не будет ни разу...

Lazy caT

И так, подытожу свои разбирательства со всем тем, что было описано выше…

Для корректной работы 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, за конструктивные предложения… :)

werter

Еще раз - пожалуйста.

P.s. И таки да , именно в 'State Type' необходим 'none' . Невнимательно глянул, пардон.