Не отрабатывает проброс произвольных портов с WAN в LAN



  • Пробросил 80 порт без проблем с внешки внутрь. По той же схеме попытался прокинуть ftp с внешки на внутренний сервер правда с использованием нестандартного порта + диапазона портов для Passive mode. Не хочет работать. На сервере в качестве gate стоит pfSense. На самом pfSense в логах фиксируется что соединение идёт но завершается CLOSED:SYN_SENT и в логах самого FileZilla Server не видно позывов к подключению, то есть пакеты не натируются внутрь сети. Почему такое может происходить или нужно как то хитро прокидывать соединение для Passive mode. А ещё не понятно как заставить psSense работать с пробросом VNC с внешки внутрь если на клиентской машине указывается гейт не шлюз pfSense. На Kerio Connect такой вариант работал вообще без проблем.



  • @marchello
    Скрины настроек пф (ЛАН, ВАН, Порт форврд) + скрины настроек FZ.

    А ещё не понятно как заставить psSense работать с пробросом VNC с внешки внутрь если на клиентской машине указывается гейт не шлюз pfSense. На Kerio Connect такой вариант работал вообще без проблем.

    Почему шлюзом не может\не должен быть пф в вашем случае? Объясните. Уверен, что можно решить и с пф в кач-ве шлюза.



  • Alias.JPG
    WAN.JPG
    LAN.JPG
    PortForward.JPG

    В настройках pfSense d в части Firewall & NAT ничего не менял всё дефолтовое. Использовать второй шлюз в составе pfSense к сожалению нельзя в силу причин шифрации трафика КШ "Застава" и закрытости сети. На клиенте гейт либо в сторону КШ "Застава" либо в сторону pfSense. Так-то я организовал авторизацию через LDAP и портал отрабатывает нормально. И доступ к внутреннему WEB серверу работает тоже без проблем а вот с ftp что то затроило, да и VNC тоже, хотя если гейт на клиенте как рекомендовано сменить на pfSense то работает, однако так не вариант делать потому как гейт Заставы в прерогативе по любому. Подскажите как заставить ftp по нестандартному 4915 ... на внутренний сервер ходить где гейтом прописан не pfSense?



  • @marchello Натировать пакеты от PFSense на lan интерфейсе ,чтобы на внутренний сервер приходили пакеты с адресом источника lan интерфейса PF . Тогда внутренний сервер будет отвечать на lan интерфейс PF , а тот , в свою очередь , дальше наружу



  • @Konstanti То есть нужно переключить NAT в ручной режим и принудительно добавить правило?



  • @marchello Совершенно верно
    Добавляете правило для исходящего Нат на LAN интерфейсе
    и избавляетесь от внешней ip адресации внутри Вашей сети для внутреннего сервера
    Если все сделаете верно , то внутренний сервер будет отвечать на LAN интерфейс PF, а тот уже дальше
    Схема будет выглядеть так
    8.8.8.8 -> 1.1.1.1 (внешний ip PF, проброс 10.10.10.11 ) -> 10.10.10.10 ( внутр ip LAN PF, меняем адрес источника) -> 10.10.10.11 (внутр сервер)
    и обратно
    10.10.10.11 ->10.10.10.10 -> 1.1.1.1 -> 8.8.8.8

    Вот как это выглядит у меня в варианте Linux ( iptables)
    Смысл , думаю , ясен
    048c8823-9d59-44d3-b502-8a96bc3239aa-image.png



  • @Konstanti Спасибо за подсказку, завтра заскочу на работу и попробую провернуть авантюру )



  • @Konstanti Попробовал переключив NAT в гибридный режим и создав вот такое правило:
    NAT-15062019.JPG

    Нет не хочет работать (((



  • @marchello

    1. уверены , что порт источника 4915 (посмотрите мой пример с Linux, вторая строка - это именно NAT ) ????
    2. попробуйте Manual Outbound NAT

    e85b6e4d-0ee8-43de-aa22-db50b46b5b90-image.png



  • @Konstanti Ну это по факту 21 порт ftp в режиме пассив с выделением дополнительных портов 4920-4930 но по старой привычке я на сервере обычно меняю стандартный порт 21 на иной )



  • @marchello
    Я про то , что Вы создали правило с портом источника 4915, а по факту порт источника может быть любым. А вот порт назначения - да , 4915.



  • @marchello said in Не отрабатывает проброс произвольных портов с WAN в LAN:

    Использовать второй шлюз в составе pfSense к сожалению нельзя в силу причин шифрации трафика КШ "Застава" и закрытости сети. На клиенте гейт либо в сторону КШ "Застава" либо в сторону pfSense

    А на Заставе завернуть ВСЕ, что идет с определенного IP на пф разве нельзя? Попробуйте.



  • @werter Заставу напрямую нам не дают рулить у нас ограниченные права ( к большому нашему сожалению



  • @Konstanti С портом источника я пробовал и any это не повлияло на результат. Прямое указание 4915 это скорее жест отчаяния )))



  • @marchello Значит что-то делаете неверно
    Tcpdump надо запускать на lan интерфейсе
    и смотреть , что происходит (например , посмотреть в каком виде уходят пакеты на нужном Вам порту в сторону внутреннего ftp-сервера )
    Еще раз обращаю внимание на мой скриншот
    1 строка - проброс портов на внутренний портовый сервер 192.168.1.230 ( источник пакета не важен , важен порт назначения на внешнем интерфейсе)
    2 строка - натирование исходящих проброшенных пакетов на интерфейсе tun100 c адресом назначения 192.168.1.230

    Вот как это выглядит через призму tcpdump
    на внешнем интерфейсе
    17.58.63.172.22715 > 37.XXX.XXX.XXX.smtp: Flags [S], seq 3057509191, win 29200, options [mss 1460,sackOK,TS val 2982516424 ecr 0,nop,wscale 7], length 0
    37.XXX.XXX.XXX.smtp > 17.58.63.172.22715: Flags [S.], seq 82960713, ack 3057509192, win 14480, options [mss 1346,sackOK,TS val 2733787062 ecr 2982516424,nop,wscale 7], length 0

    и внутреннем

    10.10.100.2.22715 > 192.168.1.230.smtp: Flags [S], seq 3057509191, win 29200, options [mss 1360,sackOK,TS val 2982516424 ecr 0,nop,wscale 7], length 0
    192.168.1.230.smtp > 10.10.100.2.22715: Flags [S.], seq 82960713, ack 3057509192, win 14480, options [mss 1346,sackOK,TS val 2733787062 ecr 2982516424,nop,wscale 7], length 0



  • @Konstanti Завтра попробую



  • @marchello said in Не отрабатывает проброс произвольных портов с WAN в LAN:

    Пробросил 80 порт без проблем с внешки внутрь

    Если вы 80-й пробрасывали НЕ для пф, то КРАЙНЕ рекомендую сменить дефолтный порт вебки пф на нестандартный. Плюс откл. авторедирект для вебки пф и РАЗРЕШИТЬ доступ к вебке только с определенных IP. И пользовать httpS, ес-но.

    Касаемо ФТП. Шлюзом у вашего ФТП должен быть пф. Проверьте это. Проблем быть в таком случае не должно.
    И самое важное. Если на пф не вкл. nat loopback, то проверять доступ ИЗВНЕ к проброшенным портам на пф нужно только с др. провайдера (напр., с моб. тел.)

    https://forum.netgate.com/topic/99643/port-forwarding-with-nat-to-internal-ip-with-different-default-gateway/



  • @werter А если гейт на клиенте в локалке не ip pfSense, работать не будет доступ из внешки на клиента в локале?



  • @marchello

    @Konstanti вам предложил схему. Попробуйте.

    Кстати, современные ОС дают возможность пользовать n-ое кол-во GW. И даже приоритезировать GW с помощью metric. Попробуйте задать в настройках проблемной машины основной Gw с метрикой 1 (Застава) и резервный с метрикой 100 (пф). Костыль, но может сработать.



  • @werter Это не отрабатывает, только вариант первый гейт пропал - подключаю следующий по весу.



  • @Konstanti Спасибо всем кто откликнулся и помог решить проблему port redirect где у локальной машины иной по отношению к pfSense Gate, и в качестве благодарности я оставлю здесь потомкам последовательность действий для организации доступа к внутренним серверам из внешки.

    1. Заходим в aliases > Ports и создаём алиас где указываем порты которые требуется пробросить наружу при этом диапазон указывается через двоеточие 4920:4930 что означает диапазон из 10 портов начиная с 4920 и заканчивая 4930.
      Alias.JPG

    2. Заходим в Firewall > NAT > Outbound и переключаем NAT в режим Hybrid Outbound NAT (Крутые перцы могут сразу переключать в Manual и убирать все автоматически генерированные правила дабы создать новые правильно)
      2fd3407d-7382-4bbc-9f7b-7f608679fb9d-изображение.png

    3. Далее создаём правило где в Destination ip адресация Вашей внутренней сети с соответствующей маской.
      93fceaf6-b98f-4013-bfd4-ca047d5bebe4-изображение.png

    4. Идём в Firewall > NAT > PortForward и создаём правила как указано в примере. После этих манипуляций Вы получите доступ к соответствующим портам локальной машины из внешки даже если гейтом на локальной машине не прописан pfSense.
      606ace01-2f14-460c-a636-75b9f82ee394-изображение.png



  • @marchello
    Спасибо )

    Source port в Outbound NAT mode можно убрать - лишнее.

    @marchello said in Не отрабатывает проброс произвольных портов с WAN в LAN:

    А ещё не понятно как заставить psSense работать с пробросом VNC с внешки внутрь если на клиентской машине указывается гейт не шлюз pfSense

    По ТЗ у вас только PC с VNC не имеет гейтом пф. Оказывается , еще и PC с FTP.



  • @werter Всё нормально, я намерено включил ещё один вариант чтобы те начинающие работать с pfsense навроде меня при поиске решения наткнулись на такой вариант. Однако с ftp происходит занятная штука ))) я без проблем подключаюсь с клиента на Андроиде но не могу подключиться с клиента установленного на ПК работающего через adsl без реального ip. При этом раньше данный комп без проблем подключался и отрабатывал когда шлюзом стоял Kerio. Даже пинг не проходит. Ну пинг pfsense видимо режет а вот какая ему разница сотовая или adsl связь это вопрос.



  • @marchello
    Уверен на 146%, что проблема не в пф.



  • @werter Да я так же был в этом уверен, но уверенность пошатнулась когда я на клиентской машине которая ходит через adsl сменил ip для доступа к ftp серверу на старый канал который ходит через шлюз Kerio. Клиент зашёл на сервер ftp как родной. При этом вчера на интерес попробовал зайти с дома, у меня выдан реальный ip и опять зашёл без проблем через канал на котором pfSense. Это странная картина. Это прозвучит странно но может фаер pfSense блокирует сети где не выдан клиенту реальный ip адрес?
    825830ea-22ee-4595-935a-44f5a40f90ce-изображение.png



  • @marchello Доброе утро
    Все просто

    1. tcpdump на wan интерфейсе ( смотрим , приходят ли пакеты, и что происходит с ними )

    2. журнал файрвола , смотрим , не блокирует ли PF что-то , приходящее с нужного ip
      если да , то смотрим номер правила , которое блокирует ,и уже от этого отталкиваемся

    3. и лично я бы сделал VPN туннель на основе PF для удаленных клиентов ( и пустил весь трафик через него)



  • @Konstanti Доброго утра, да вчера я запускал на клиенте удалённо через AnyDesk пинги до pfSense но не смог добиться разрешения на ответ клиенту со стороны pfSense. Хотя на WAN я создал явное правило разрешения трафика по протоколу ICMP.



  • @marchello
    У ФТП-сервера шлюзом пф ? Или опять какое-то "извращение" ?

    Хотя на WAN я создал явное правило разрешения трафика по протоколу ICMP.

    Скрин правил на WAN покажите.

    @Konstanti

    я бы сделал VPN туннель на основе PF для удаленных клиентов ( и пустил весь трафик через него)

    ЛЮТО плюсую. Один-два порта для ВСЕГО. Плюс секурность.
    Уверен ,что у ТС фтп без шифрования.



  • @marchello

    Насчет Зюхеля. У него в настройках есть NAT Helper (ALG)? Если есть, то выкл. его.


Log in to reply