[РЕШЕНО] Проброс нестандартного порта



  • P.S. Проблема решена - что-то не так было в внутренних настройках ADSL модема по одному из интерфейсов. После перевода его из режима Routing в Bridge все заработало как надо. Настройки второго модема оставлены в Routing - с ним проблем нет.

    Изучаю pfSense 2.0, никак не получается пробросить в локалку порт с заменой на другой. Догадываюсь, что проблема для гуру пустяковая, но у меня таких замен используется много, нужно ее решить…
    Есть машина с 2-мя WAN и одним LAN. Нужно с обоих внешних интерфейсов пробросить порт 8888 на порт 80. Экспериментирую пока с одним интерфейсом. Настройки в новом правиле Port Forward выставил следующие:
    Interface: UTEL
    Protocol: TCP
    Source: any
    Source port: any
    Destination: not, Type: UTEL address
    Destination port: 8888
    Redirect IP: 192.168.10.14
    Redirect port: HTTP

    Правило записывается в NAT, в Rules создается свое. И не пускает. Прежде чем писать сюда в каких только вариантах не перепробовал настройки Source, Destination, Redirect - выше описан вариант из последних попыток. Подозреваю что-то где-то остается закрытым, нужно еще что-то прописать (то ли в RULES для локалки, то ли в NAT Outbound). Прошу помочь или подсказать где посмотреть...



  • А вы из локальной сети проверяете редирект? Если да то добавьте галочку - http://thin.kiev.ua/index.php?option=com_content&view=article&id=399:-pfsense-20&catid=50:pfsense&Itemid=81#LAN



  • @dr.gopher:

    А вы из локальной сети проверяете редирект?

    Спасибо что откликнулись.
    Нет, проверяю как раз из внешнего источника (есть возможность). Статью видел, галочку на всякий случай как раз после ее прочтения убрал. Это не помогло.



  • Destination: not, Type: UTEL address вот это что?
    И будьте добры скриншоты правил редиректа и соотв. ему правил файрвола.



  • @dvserg:

    Destination: not, Type: UTEL address вот это что?
    И будьте добры скриншоты правил редиректа и соотв. ему правил файрвола.

    UTEL - это переименованный в настройках интерфейсов WAN.
    Скриншоты прилагаю






  • Посмотрите еще раз
    Destination: not, Type: UTEL address - здесь по русски звучит как пакеты_которые_не_на_UTEL_address . Вопрос кто в таких условиях будет работать?

    Галку NOT убрать нужно.



  • @dvserg:

    Посмотрите еще раз
    Destination: not, Type: UTEL address - здесь по русски звучит как пакеты_которые_не_на_UTEL_address . Вопрос кто в таких условиях будет работать?

    Галку NOT убрать нужно.

    В принципе я так и думал. На установку флага NOT меня натолкнул Ваш пост из темки "FAQ - ссылки на популярные темы - Мапинг портов в pfSense 2.x на примере RDP протокола". И в ней же есть Ваши рекомендации - должны быть "На LAN настроены разрешающие правила для локальной подсети". Может я тут чего не так сделал?
    Повторюсь, пробовал по-разному - и с установленным флагом, и без него. Не пробрасывает.



  • Вот скриншот моих правил для локалки - все сгенерировано автоматически.
    Небольшой комментарий к скриншоту:
    UTEL - это WAN
    LOCAL - это LAN
    VEGA - это OPT1
    InetGroup - это объединенные в группу интерфейсы UTEL и VEGA (все, что смотрят в Интернет)




  • Кстати, я никак не могу добиться чтобы из верхнего правила для локальной сети ушел порт 80. На странице System: Advanced: Admin Access я выбираю протокол HTTPS и ставлю галочку WebGUI redirect: Disable webConfigurator redirect rule - а он остается. Или так надо?
    Впрочем не важно. Портмаппинг меня интересует больше… :)



  • @V_V_V:

    @dvserg:

    Посмотрите еще раз
    Destination: not, Type: UTEL address - здесь по русски звучит как пакеты_которые_не_на_UTEL_address . Вопрос кто в таких условиях будет работать?

    Галку NOT убрать нужно.

    В принципе я так и думал. На установку флага NOT меня натолкнул Ваш пост из темки "FAQ - ссылки на популярные темы - Мапинг портов в pfSense 2.x на примере RDP протокола". И в ней же есть Ваши рекомендации - должны быть "На LAN настроены разрешающие правила для локальной подсети". Может я тут чего не так сделал?
    Повторюсь, пробовал по-разному - и с установленным флагом, и без него. Не пробрасывает.

    Ну да, похоже там ошибка… сори - исправим.



  • @dvserg:

    Ну да, похоже там ошибка… сори - исправим.

    Ну я эту ссылку указал не с намеком на какие-то претензии к Вам, даже в мыслях не было..  :)  Бог с ней, с ошибкой в посте. Меня больше моя насущная проблема интересует.  :)
    Если Вы говорите, что настройки какие я указал выше, нормальные и мне нужно просто убрать NOT, тогда я ничего не понимаю - я так делал.
    У меня оба подключения ADSL. И оба в режиме Routing, с пробросом ВСЕХ портов на определенный IP, который я потом назначаю сетевым карточкам на своем шлюзе. Для KerioWinroute, который я использую сейчас (и хочу заменить на pfSense) этого достаточно, все нормально пробрасывает. Может pfSense требует включения Bridge для нормальной работы?
    И можно попросить выложить скриншот настроек NAT нормально работающего портмаппинга на локальную машину? Без правил в Routing, все равно зависимое и почти не редактируется…



  • У меня оба подключения ADSL. И оба в режиме Routing, с пробросом ВСЕХ портов на определенный IP, который я потом назначаю сетевым карточкам на своем шлюзе. Для KerioWinroute, который я использую сейчас (и хочу заменить на pfSense) этого достаточно, все нормально пробрасывает. Может pfSense требует включения Bridge для нормальной работы?

    Сделайте бридж.



  • @dvserg:

    Сделайте бридж.

    Сделал. Заработало! Спасибо!
    Все таки что-то не так было в ADSL модеме именно по WAN (у меня UTEL). Перевел в Bridge только его. Второй оставил как есть, создал для него правило по образу первого - и он тоже работает! Самое смешное, что я за два дня мучений ни разу не попробовал второе подключение. Ладно, будет наукой - зря грешил на pfSens… Хотя на виндовом роутере модем отрабатывал и через Routing...



  • Первый WAN обычно маршрут по умолчанию, думаю это как-то связано с ним.


Locked