Pfsense блокирует все входящие соединения



  • Добрый день.
    Pfsense v.2.4.3_1
    Структура сети простая: ISP->Pfsense->LAN
    2 интерфейса - один WAN, второй LAN.
    Теперь проблема:
    После смены провайдера не работают телефония (asterisk), не работают пробросы снаружи вовнутрь сети (SSH, RDP и тд.). По факту изменились: внешний IP, DNS. Вопрос телефонии решили (не через pfsense). Провайдер ничего не блокирует (проверено). Хочется понять почему Pfsense больше не принимает соединения.

    Доп. инфо:
    Изнутри работает интернет и все что инициируется изнутри. Например RDP спокойно ходит наружу.
    Если инициировать сессию RDP снаружи то блочится и это видно в логах фаерволла.

    Что было сделано:
    перепроверены правила проброса, удалены правила проброса, сделаны заново, проверены тремя людьми (что конечно не гарантия правильности, но все же), pfsense обновлен до текущей версии с версии 2.3.х., выкурено большое количство мануалов, nat правила проверены по местному чек-листу, убит и восстановлен шлюз по умолчанию.

    пример правила в фаерволе :
    0_1533831171738_Снимок.PNG
    и nat:

    0_1533831176893_Снимок2.PNG

    как уже отметил - все это блокируется фаерволлом и видно в логах.
    0_1533831545339_Снимок3.PNG

    если тыкнуть в красный крест, то

    0_1533831570673_Снимок4.PNG

    Буду признателен за идеи.



  • @destress_signal said in Pfsense блокирует все входящие соединения:

    пример правила в фаерволе

    А собственно port forward настроен? Обычно при создании port forward PF сам создает (если это не отключено) соответствующее правило на WAN, добавляя к нему NAT...



  • Если тот что Firewall->Nat->Port Forward то да.
    Собственно второй скрин именно оттуда.



  • Небольшое дополнение:
    отключение правила Deny All - не спасает ситуацию.
    Ipsec туннель живет без проблем, но тут скорее всего потому, что поднимается он от меня. Из дома попробую OpenVPN подключить.



  • @destress_signal said in Pfsense блокирует все входящие соединения:

    Собственно второй скрин именно оттуда.

    Просмотрел.
    Для тестирования "открытости" порта попробуйте, например,
    http://canyouseeme.org
    Не придется привлекать для этого добровольцев.
    Правило "Deny all" когда-либо существовало?
    Сходите
    http(s)://ip_pfsense/status.php
    Грузится долго. Все настройки на одной странице. Есть там упоминания о "Deny all"?

    Приведите скриншот всех правил на WAN.

    Не думаю, что новый провайдер подсунул вам "серый" IP...
    Если конфигурация несложная - сбросьте настройки и восстановите их вручную.



    1. как и предполагалось - порт 3389 закрыт

    2. Правило Deny есть и сейчас
      3 Все правила на WAN интерфейсе
      0_1533838218297_Снимок7.PNG
      извиняюсь если мелко - могу покрупнее сделать.

    3. конфигурация (кроме Ipsec) не сложная - можно восстановить руками. Да и Ipsec тоже.
      Просто хотелось бы разобраться с чем имею дело - личная кривизна рук или неизведанное в Pfsense

    4. Сброс уже запланирован на субботний вечер.



  • На status.php - 15 упоминаний о Deny ALL.

    Подозрение что у меня в правилах дублирование запрещений?



  • @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, снаружи порт закрыт.



  • Добрый.

    1. Отключить блокирующее всё правило.
    2. Проверить, что у вас не "серый" ip на WAN. Заходите в Status->Interfaces и на 2ip.ru. Сравниваете , что у вас на WAN и что показывает 2ip.

    P.s. У вас много "кривых" правил на WAN. Оч. много (



  • Доброго дня
    Попробуйте отключить первое правило , блокировать частные сети
    Я вот , например , вижу , что вы хотите пропускать трафик от 10.7.4.0 , а он уже изначально заблокирован
    0_1534325261481_f091fea6-56af-4a18-8b21-7ebae465168e-image.png



  • @konstanti said in Pfsense блокирует все входящие соединения:

    Доброго дня
    Попробуйте отключить первое правило , блокировать частные сети
    Я вот , например , вижу , что вы хотите пропускать трафик от 10.7.4.0 , а он уже изначально заблокирован
    0_1534325261481_f091fea6-56af-4a18-8b21-7ebae465168e-image.png

    @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 Блин
    так и есть - у него адрес серый
    0_1534347113440_ca7ba058-e4ca-4851-907b-9ac29fe6e5f6-image.png
    вот же четко видно 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 . Обычно лучше смотреть содержимое файла с правилами , там четко видно как пакет идет и в какой момент какое правило срабатывает


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy