[РЕШЕНО] Проброс нестандартного порта
-
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 обычно маршрут по умолчанию, думаю это как-то связано с ним.