Измучился с пробросом портов
-
У меня работает подобная комбинация.
WAN TCP * * * 1111 192.168.0.215 80 (HTTP)
Попробуйте
Вместо
Destination= WAN address
использовать
Destination= ANY -
Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.
-
Отключите файрволл на 192.168.0.101
Подымите на 192.168.0.101 еще какую-нибудь службу, если это Виндовс - включите тот же RDP и попробуйте аналогичное на нем, например - WAN:33398->192.168.0.101:3389 -
Файрвол на 192.168.0.101 выключен, другие службы включая RDP (порт 3389) пробрасываются без проблем. То есть набрав к примеру 89.178.14.21:3555 я подключаюсь по RDP на 192.168.0.101
-
Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.
А нету ли на pfsense squid'a в прозрачном режиме?
-
Сделал по Вашей рекомендации - не помогло. Не понятно почему с 80 на 80 все работает, а с 555 на 80 нет … уже весь мозг сломал.
А нету ли на pfsense squid'a в прозрачном режиме?
Да, явно что-то мешает.
Попутно вопрос. Port forward активно и давно использую. И с мультиваном и без. И ни разу не использовал поле
Destination= WAN address (по умолчанию там ANY)
И все всегда работает. Что я делаю не так? -
А нету ли на pfsense squid'a в прозрачном режиме?
Стоял - полностью удалил и перезагрузил pfsense. Не помогло
Может быть в system \ advanced где-то галочка не там стоит? Сейчас стоят на:
Enable webConfigurator login autocomplete
Disable HTTP_REFERER enforcement check
Enable Secure Shell -
А что насчет WebGUI redirect?
У меня эта галка не отмечена.Включите лог для этого правила на WAN.
-
WebGUI redirect у меня тоже не отмечена. А где включается лог для этого правила на WAN? И как потом увидеть результат?
-
WebGUI redirect у меня тоже не отмечена. А где включается лог для этого правила на WAN? И как потом увидеть результат?
При создании порт форвард создается правило на WAN, обычно начинается со слова NAT. В нем есть пункт Log packets that are handled by this rule.
Смотреть - Status - System Logs - Firewall -
А что там смотреть "Источник" и "Назначение", больше ничего. Не понятно, почему все остальные порты пробрасываются а именно 80 блочится?
-
Попробовал сделать проброс 80 порта на системе Monowall (аналог pfsense), там все сразу заработало без проблем. Так что вывод очевиден - в pfsense где-то стоит секретная галочка.
-
А если использовать не 555, а 5555, например?
И сбросить states\перегрузить pf? -
ВЕБ морда pfsense на HTTP или на HTTPS ?
-
на HTTPS (443 порт), пробовал даже на 10000 порт ее переводил - не помогло.
В NAT переделал правило на 5555 порт, перезагрузил - не помогло.
Кстати, когда заходишь через браузер извне, после IP адреса прописывается xx.xx.xx.xx/index.x?theme=800x480 , то есть он нащупывает web интерфейс и тут же блочит. Просто когда заходишь на устройство из локальной сети в адресной строке присутствует этот же фрагмент среди всего остального. -
после IP адреса прописывается xx.xx.xx.xx/index.x?theme=800x480 , то есть он нащупывает web интерфейс и тут же блочит. Просто когда заходишь на устройство из локальной сети в адресной строке присутствует этот же фрагмент среди всего остального.
Ничего из вышеописанного не наблюдаю
-
Отображения в адресной строке могут отличаться. т.к. у нас разные устройства. Тут просто интересен сам факт, что устройство как бы "прощупывается" извне и тут же блочится.
-
пробуй ВЕБ перевести на HTTP, и порт задай например 180
(как я думаю это освободит 80 порт -
Перенес WEB на HTTP и указал 180 порт, зашел на 192.168.0.1:180, перезагрузил pfsense - не помогло.
-
А не может ли быть дело в настройках собственно web-сервера на целевой машине?
Остановите его, установите простенький HFS
http://www.rejetto.com/hfs/
и попробуйте с ним.