Блокируется проброс порта
-
А адрес 172.16.33.128 у Вас со стороны WAN? В настройках интерфейса WAN опция Block private networks отмечена?
Да отмечена, все за ваном сейчас , но это я уже делаю для удобства, ибо переключать на рабочую сеть нет времени.
схема такая воткнул два шнурка wan 172.16.0.182 lan 172.16.0.181 и делаю проброс с wan 172.16.0.182:9987 на 172.16.0.153:9987 соответсвенно делаю конект с
172.16.33.128 на 172.16.0.182:9987 должен попасть сюда 172.16.0.153:9987,но блокируеться
По правельному на wan белый ip на lan 172.16.0.181 и делаю проброс на 172.16.0.153:9987 не работает. Так как нет времени для проверки почему, использую первый вариант -
… схема такая воткнул два шнурка wan 172.16.0.182 lan 172.16.0.181 и делаю проброс с wan 172.16.0.182:9987 на 172.16.0.153:9987 ...
маски какие на интерфейсах? они в одной сети?
NAT:Outbound: и LAN и WAN. (!?)
-
маски одинаковые, все в одной сети, собственно какая разница то?Принцип работы то не изменился
поднят у меня сервис на машине 172.16.0.153:9987 я на него прилипаю с любой машины по этому адресу, но его нужно вывести в инет. Я хочу проверить все локально чтоб потом просто переткнуть шнурок с инетом и сменить адрес ван.По этому дал два локальных шнурка ему. -
маски одинаковые, все в одной сети, собственно какая разница то?Принцип работы то не изменился
Разница как-раз есть и принцип работы разный.
Роутер - он, понимаете, должен знать куда и как передавать пакеты.
А по Вашему подключению он ведет себя, как Буриданов осел. -
А адрес 172.16.33.128 у Вас со стороны WAN? В настройках интерфейса WAN опция Block private networks отмечена?
Эта опция - на вкладке Firewall:WAN правило #1, необходимо снять для тестов с локальными сетями. Там есть и другая опция, которую для новичка и его тестов тоже лучше выключить. При реальном использовании на WAN интерфейсе это полезные и нужные опции. Расписывать не буду - в поиске есть.
ИМХО: это выходит не тест - это выходит ерунда. Вот маршрутизировать пакет pfsensy на какой интерфейс? Я так не "мучил" pfsense, но думаю что если подключиться в такой случае на WAN - с WAN интерфейса пакет и должен будет уйти, т.к. это его подсеть. В такой случае логично включить Bypass firewall rules for traffic on the same interface - которая при реальном использовании на WAN Вам не нужна.
К тому же Nat:Outbound нужно убрать правило для LAN - зачем NAT-ить в LAN?
Как должен ответить клиентский комп с ip 172.16.0.153 через pfsense? Как минимум запрос должен придти не с ip адреса той же подсети, и шлюзом для этого клиента в идеале должен быть LAN адрес pfsense.
на вкладке Firewall:WAN правило #4 никогда не будет выполнено, т.к. будет выполнено правило #3 как "более общее" правило
для подобной проверки Вам лучше использовать 2 порта свитча для имитации Интернета (один: для компьютера/ноутбука, второй для WAN pfsense, назначить им ip из одной подсети, но отличной от той, что используется в локальной сети), LAN pfsense подключить к испытуемому комп, или в локальную сеть. Вот и пытайтесь тогда из WAN достать до того компа (на WAN интерфейсе можно все и всем пока тогда разрешить (как минимум по http на WAN address дать доступ отдельным правилом и поставить его)).
-
маски одинаковые, все в одной сети, собственно какая разница то?Принцип работы то не изменился
Разница как-раз есть и принцип работы разный.
Роутер - он, понимаете, должен знать куда и как передавать пакеты.
А по Вашему подключению он ведет себя, как Буриданов осел.Ну если верить логам то он все понимает раз пишет в dest конечный ip только вот трафик он блокирует…
Суть найти причину почему не работает в рабочих условиях, изначально я все сделал по мануалу на реальной сети с интернетом провайдера на wan и lan в мою сеть, и так же не работало, и разве обязательно pfsense быть шлюзом для компьютера с сервисом? Из рабочего варианта сейчас стоит dfl 860e на ней два правила одно sat второе allow, и через нее я прилипаю к сервису как из дома так и с этой же сети при этом в клиенте всегда указан wan ip, а шлюзом может быть как сама dfl так и любой другой шлюз -
маски одинаковые, все в одной сети, собственно какая разница то?Принцип работы то не изменился
Разница как-раз есть и принцип работы разный.
Роутер - он, понимаете, должен знать куда и как передавать пакеты.
А по Вашему подключению он ведет себя, как Буриданов осел.Ну если верить логам то он все понимает раз пишет в dest конечный ip только вот трафик он блокирует…
Суть найти причину почему не работает в рабочих условиях, изначально я все сделал по мануалу на реальной сети с интернетом провайдера на wan и lan в мою сеть, и так же не работало, и разве обязательно pfsense быть шлюзом для компьютера с сервисом? Из рабочего варианта сейчас стоит dfl 860e на ней два правила одно sat второе allow, и через нее я прилипаю к сервису как из дома так и с этой же сети при этом в клиенте всегда указан wan ip, а шлюзом может быть как сама dfl так и любой другой шлюзДля эффективного выполнения целей нужно использовать средства по их назнвачению. Все ответы уже выше есть. В данном случае блокировка правилом №1 на WAN интерфейсе - нужно снять галку Block private networks в настройках WAN интерфейса.
НО! То как сейчас все устроено - это неправильно с точки зрения маршрутизации сетей! Учите матчасть! Как можно проделать Ваш тест я уже писал:
для подобной проверки Вам лучше использовать 2 порта свитча для имитации Интернета (один: для компьютера/ноутбука, второй для WAN pfsense, назначить им ip из одной подсети, но отличной от той, что используется в локальной сети), LAN pfsense подключить к испытуемому комп, или в локальную сеть. Вот и пытайтесь тогда из WAN достать до того компа (на WAN интерфейсе можно все и всем пока тогда разрешить (как минимум по http на WAN address дать доступ отдельным правилом и поставить его)).
-
FAQ https://forum.pfsense.org/index.php?topic=22839.0
В том числе мапинг портов.
В том числе мапинг портов когда pfSense не является шлюзом по умолчанию. -
У меня пока не изменил System: Advanced: Firewall and NAT->NAT Reflection mode for port forwards
Из вешки почему-то не пробрасывалось. -
сейчас пойду поставлю в рабочую сеть, посмотрю еще раз