Pfsense блокирует все входящие соединения
-
Доброго дня
Попробуйте отключить первое правило , блокировать частные сети
Я вот , например , вижу , что вы хотите пропускать трафик от 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 Думается мне ,что где-то провайдер поменяет адрес назначения с белого на свой внутренний серый . Это не самое страшное
-
@destress_signal блин. всего то, а мы тут сидим ссоримся =)))
-
Извините :) просто после восстановления сенса пришлось немного поработать :) только вернулся в реальный мир
-
@destress_signal Отлично , как я и подумал , глюк PF . Обычно лучше смотреть содержимое файла с правилами , там четко видно как пакет идет и в какой момент какое правило срабатывает