[РЕШЕНО] Проброс нестандартного порта
-
А вы из локальной сети проверяете редирект? Если да то добавьте галочку - http://thin.kiev.ua/index.php?option=com_content&view=article&id=399:-pfsense-20&catid=50:pfsense&Itemid=81#LAN
-
А вы из локальной сети проверяете редирект?
Спасибо что откликнулись.
Нет, проверяю как раз из внешнего источника (есть возможность). Статью видел, галочку на всякий случай как раз после ее прочтения убрал. Это не помогло. -
Destination: not, Type: UTEL address вот это что?
И будьте добры скриншоты правил редиректа и соотв. ему правил файрвола. -
Destination: not, Type: UTEL address вот это что?
И будьте добры скриншоты правил редиректа и соотв. ему правил файрвола.UTEL - это переименованный в настройках интерфейсов WAN.
Скриншоты прилагаю
-
Посмотрите еще раз
Destination: not, Type: UTEL address - здесь по русски звучит как пакеты_которые_не_на_UTEL_address . Вопрос кто в таких условиях будет работать?Галку NOT убрать нужно.
-
Посмотрите еще раз
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 - а он остается. Или так надо?
Впрочем не важно. Портмаппинг меня интересует больше… :) -
Посмотрите еще раз
Destination: not, Type: UTEL address - здесь по русски звучит как пакеты_которые_не_на_UTEL_address . Вопрос кто в таких условиях будет работать?Галку NOT убрать нужно.
В принципе я так и думал. На установку флага NOT меня натолкнул Ваш пост из темки "FAQ - ссылки на популярные темы - Мапинг портов в pfSense 2.x на примере RDP протокола". И в ней же есть Ваши рекомендации - должны быть "На LAN настроены разрешающие правила для локальной подсети". Может я тут чего не так сделал?
Повторюсь, пробовал по-разному - и с установленным флагом, и без него. Не пробрасывает.Ну да, похоже там ошибка… сори - исправим.
-
Ну да, похоже там ошибка… сори - исправим.
Ну я эту ссылку указал не с намеком на какие-то претензии к Вам, даже в мыслях не было.. :) Бог с ней, с ошибкой в посте. Меня больше моя насущная проблема интересует. :)
Если Вы говорите, что настройки какие я указал выше, нормальные и мне нужно просто убрать NOT, тогда я ничего не понимаю - я так делал.
У меня оба подключения ADSL. И оба в режиме Routing, с пробросом ВСЕХ портов на определенный IP, который я потом назначаю сетевым карточкам на своем шлюзе. Для KerioWinroute, который я использую сейчас (и хочу заменить на pfSense) этого достаточно, все нормально пробрасывает. Может pfSense требует включения Bridge для нормальной работы?
И можно попросить выложить скриншот настроек NAT нормально работающего портмаппинга на локальную машину? Без правил в Routing, все равно зависимое и почти не редактируется… -
У меня оба подключения ADSL. И оба в режиме Routing, с пробросом ВСЕХ портов на определенный IP, который я потом назначаю сетевым карточкам на своем шлюзе. Для KerioWinroute, который я использую сейчас (и хочу заменить на pfSense) этого достаточно, все нормально пробрасывает. Может pfSense требует включения Bridge для нормальной работы?
Сделайте бридж.
-
Сделайте бридж.
Сделал. Заработало! Спасибо!
Все таки что-то не так было в ADSL модеме именно по WAN (у меня UTEL). Перевел в Bridge только его. Второй оставил как есть, создал для него правило по образу первого - и он тоже работает! Самое смешное, что я за два дня мучений ни разу не попробовал второе подключение. Ладно, будет наукой - зря грешил на pfSens… Хотя на виндовом роутере модем отрабатывал и через Routing... -
Первый WAN обычно маршрут по умолчанию, думаю это как-то связано с ним.