Pfsense блокирует все входящие соединения
-
@destress_signal
Да, непросто у вас на WAN.Deny all стоит выше, и все, что ниже его - 3389-Nat test, SIP from MA, следовательно, работать не могут.
Более того, Deny all не нужен вовсе, PF не пропускает снаружи ничего, что явно не разрешено.
Хотите видеть Deny all в списке - поставьте его самым последним, работать оно не будет, но "admin power" изображать будет.
Правила, касающиеся доступа локальных сетей (all from Ipsec ) должны находиться в Firewall-Rules-IPsec, никак не в WAN.
Многие правила мне вообще непонятны.
@destress_signal said in Pfsense блокирует все входящие соединения:Сброс уже запланирован на субботний вечер.
Пожалуй, это может быть правильным решением.
-
@pigbrother
Спасибо за внимательность и время.Про Ipsec правила согласен - они давно на интерфейсе Ipcec. Тут это просто мусор. касательно остального - завтра еще раз попробую, но отсутствие правила Deny All - картину не меняет. По крайней мере проброс 3389 не дает возможности подключится по RDP. В любом случае согласен - причесать нужно.
-
@destress_signal чудес не бывает.
@destress_signal said in Pfsense блокирует все входящие соединения:
nat правила проверены по местному чек-листу,
Имеется в виду это?
https://www.netgate.com/docs/pfsense/nat/port-forward-troubleshooting.html -
@pigbrother
Согласен, чудес не бывает. Поэтому крайне охота докопаться до сути проблемы (кроме той что pfsense админили 5 разных человек за последние 3 года). Скорее всего после сброса сенса и восстановления правил ручками все заработает. Но как уже сказал - хотелось бы разобраться.Мусорные правила и неактуальные я почистил. Правило Deny All убрал совсем. Пока что результат - неуспех.
-
@destress_signal
Включите RDP на любом компе в LAN, у которого PF - default gateway и отключен брандмауэр. Создайте временно port forward RDP для этого ПК
Проверьте открытость порта 3389 с помощью
http://canyouseeme.org -
@pigbrother
Это было сделано, пару дней назад. Собственно так и понял что Pfsense дает отлуп по всем портам внешнего интерфейса (потом пробовал проброс разных портов).
На компьютере отключен брандмауэр, Pfsense для него default gateway, снаружи порт закрыт. -
Добрый.
- Отключить блокирующее всё правило.
- Проверить, что у вас не "серый" ip на WAN. Заходите в Status->Interfaces и на 2ip.ru. Сравниваете , что у вас на WAN и что показывает 2ip.
P.s. У вас много "кривых" правил на WAN. Оч. много (
-
Доброго дня
Попробуйте отключить первое правило , блокировать частные сети
Я вот , например , вижу , что вы хотите пропускать трафик от 10.7.4.0 , а он уже изначально заблокирован
-
@konstanti said in Pfsense блокирует все входящие соединения:
Доброго дня
Попробуйте отключить первое правило , блокировать частные сети
Я вот , например , вижу , что вы хотите пропускать трафик от 10.7.4.0 , а он уже изначально заблокирован
@destress_signal послушайте товарища. дело говорит.
intefaces->wan->block private networks && block bogon networks -
@konstanti said in Pfsense блокирует все входящие соединения:
Я вот , например , вижу , что вы хотите пропускать трафик от 10.7.4.0 , а он уже изначально заблокирован
@igroykt said in Pfsense блокирует все входящие соединения:
intefaces->wan->block private networks && block bogon networks
То есть предполагается, что к WAN идут обращения из private и bogon networks? ТС спрашивали сразу и он утверждал что " на WAN IP "белый.
-
@pigbrother я сделал такой вывод ,глядя на правила
-
@konstanti said in Pfsense блокирует все входящие соединения:
я сделал такой вывод ,глядя на правила
Абсолютно логичный вывод. Но если IP на WAN - "серый" вся тема
Pfsense блокирует все входящие соединения
не имеет смысла. -
@pigbrother есть еще 1 идея
глядя на картинки я засомневался , кто-то посередине зачем-то поставил запрещающее правило ((( где четко видно , что срабатывает только оно
ТС если можно покажите пож
кусочек из файла /tmp/rules.debug
в той части , где описываются правила интерфейса WAN -
@pigbrother айпи насколько знаю считается серым если трафик к нему ходит через nat т.е.прямой доступ к хосту с такого адреса не получить (не будет работать например проброс портов).
то что адрес в приватной сети я думаю тут нет ничего зазорного и это не значит что нет прямого доступа к хосту. вроде бы все это просто относится к классификации сетей (мол provider independent ip или provider dependent и .т.д.). -
@igroykt Блин
так и есть - у него адрес серый
вот же четко видно 10.7.1.172 - получатель -
@konstanti тогда почему это дошло до его маршрутизатора и фаервол зафиксировал сие событие? или его провайдер прокидывает rdp всем своим клиентам?
-
@igroykt вот смотрите, что еще видно
то что вижу - 3389 порт заблокирован /верно
потому что запрещающее правило стоит выше разрешающего и есть опция QUICK - чик и оно сработало ( так что все логично)
Мое мнение такое - убирать нафиг все правила WAN , проверить FLOAT , чтобы было чисто , и потом уже по 1 правилу добавлять
ТС - запрещающее правило ставить не обязательно , оно есть по умолчанию , просто срабатывает последним (оно неявное) -
@konstanti а то что вижу я это то что пакет был отфильтрован его фаерволом (то бишь его маршрутизатором) следовательно он долетел до его маршрутизатора. был бы серый адрес то фаервол провайдера бы отфильтровал и следовательно до его маршрутизатора пакет бы не долетел.
-
Доброго всем времени суток и спасибо за отзывчивость.
Вопрос уже носит чисто академический характер. В субботу сбросил свой сенс и все сделал снова. Все работает все отлично.
Касательно ваших предположений:
Внешний ip белый 100%
Запрещающее правило в середине - на момент деланья скриншота попало случайно.
Само запрещающее правило отключалось - результата не было.
Сеть 10.7.4.0 - к вопросу не относится (и этой сети на момент проблем уже не было в живых). Просто не почистил правила. -
@igroykt Думается мне ,что где-то провайдер поменяет адрес назначения с белого на свой внутренний серый . Это не самое страшное
