Файрволл игнорирует разрешающее правило
-
Друзья, доброго времени суток. Уже всю голову сломал над странным поведением файерволла.
Суть: некоторое время в тестововм продакшене стоит сервер ПФсенс. Необходимо зацепить клиентов OpenVPN.
В процессе настройки клиентов ОпенВПН увидел, что файр блокирует входящие соединения от клиента на WAN интерфейс на станадртный порт (1194) не смотря на то, что было создано разрешающее правило в ходе Визарда ОпенВПН.- Попытался сделать правило самостоятельно
- поменять на другой нестандартный порт (правило изменял соотв-щим образом)
- на всех этапах пробовал добавлять разрешающее правило из "Status: System logs: Firewall" - "Easy rule: pass this traffic"
Все эти действия не помогли. Блокирование трафика не отменилось…
Помогите, пожалуйста, у кого есть какие идеи.
PfSense 2.1.5 x64 на физическом хосте.
Друзья, ну не серчайте пожста... Добавляю скрины.
Пояснения к ним:
93.124. - Клиент ОпенВПН
81.200. - WAN порт ПФсенса
:23168 - порт на который коннектятся ОпенВПН клиенты.
 -
Скрины правил.
P.s. Ув. модераторы.
Добавьте ,пожалуйста, в "шапку" по пунктам шаблон "заявки" на помощь. Типа :1. Описать кратко и понятно проблему.
2. Приложить схему сети.
3. Приложить необходимые скрины интерфейса pfsense.Ибо отвечающе-помогающие просто залюбились уже :'(
-
Добавьте ,пожалуйста, в "шапку" по пунктам шаблон "заявки" на помощь. Типа :
1. Описать кратко и понятно проблему.
2. Приложить схему сети.
3. Приложить необходимые скрины интерфейса pfsense.Версия PfSense.
Битность.
Перечень установленных пакетов и поднятых служб. (сквид, сквид гвард, PPTP, OPENVPN).
Устовлен в отдельном "тазике" или в виртуалке. Если в виртулке то в какой. -
Добавил скрины, надеюсь этого достаточно будет
-
Поднять правила в самый верх пробовали?
Попробуйте включить отображение названий правил в логах и посмотреть каким правилом идет блокировка.
-
Правила поднимать вверх пробовал - та же история.
Блокируется дефолтным правилом. Забыл указать.
 -
Скрин настроек OpenVPN-сервера на pfsense покажите.
-
В общем, друзья, я в полном недоумении…
Сегодня нужно было добавить ИП-адрес, для выхода в интернет через исходящий НАТ. Буквально вчера это проделывал для других адресов - все сработало отлично. После - ковырялся с ОпенВПН. А сегодня - добавил, но настройки проигнорились, также как и игнорились разрешающие правило для входящего трафика ОпенВПН.
Ребутнул сервер, и о мазафака, вообще через исходящий НАТ перестал ходить трафик, ходя до ребута, для старых адресов, которым был открыт доступ - правило работало :o :o :o
Сервер экстренно заменили на старый, с другим ПО, разбираться было некогда. Завтра буду пробовать глядеть, но уже в сферическом вакууме (придется менять сетевые настройки сетевых карт ВАН и ЛАНов), что могло послужить причиной данных чудес. Сквид кстати работал нормально и с самого пфсенса пинги в ВАН уходят. Из ЛАН1 в ЛАН2 тоже трафик ходит норм. Т.е. как будто исходящий НАТ "накрылся". По логам файра смотрел - блокирования соотв-щего трафика нет.
Одни эмоции в общем в уме))) В общем в очередной раз складывается впечатление, что от лишнего чиха сабж может сильно закапризничать. -
может сделать сброс к заводским настройкам и загрузить настройки из бэкапа?
-
Сделал, не помогло.
Но помогло переключение флага с ручного управления НАТом, на автоматическое и обратно)
Проблема с блокирование трафика по прежнему актуальна. -
Дайте вывод pfctl -s nat && pfctl -s rules из Diagnostics -> Command
-
Друзья, всем спасибо за внимание! Решение найдено, с одной стороны я сам себе дурак, с другой - косяк разрабов.
Источник проблемы: в исходящем НАТе было правило, в котором фигурировал алиас. Я этот алиас переименовал. А в этом правиле НАТа он не переименовался, чего я и не заметил своевременно. В итоге наблюдались вышеперечисленные мною проблемы с файерволлом.
Сейчас трафик ОпенВПН благополучно проходит, туннель поднялся.Вообще неплохо бы о данном баге разрабам сообщить, думаю. Костыль очень больно бьет и не сразу понятно откуда ноги растут у бага.
