Pfsense проброс портов не работает

Проброс портов в pfSense для удаленного доступа

Сейчас мы сделаем проброс портов через pfsense до рабочей станции, находящейся в нашей локальной сети. Простыми словами, предоставим удаленный доступ пользователю.
Pfsense у нас уже установлен и работает в качестве шлюза между провайдером и внутренней сетью 192.168.1.0 / 24. Инструкцию по установке и настройке можно посмотреть на этой странице: установка и настройка pfsense в качестве шлюза
Перед началом настроек сделайте резервное копирование в веб — конфигураторе на странице diagnostics — backup/restore и откройте на рабочей станции порт 3389.

У нас есть:
Компьютер с железом (шлюз):
CPU — Intel® Celeron® Processor E3300 (1M Cache, 2.50 GHz, 800 MHz FSB)
NIC — внешняя — TP — link TG — 3269
NIC — встроенная — Realtek
RAM — 2 GB
HDD — Samsung HD160HJ
Motherboard — Asustek P5KPL-AM IN/ROEM/SI
Компьютер (рабочая станция)
Два патч — корда: один подключен к провайдеру и во встроенную сетевую карту шлюза, другой к рабочей станции и к внешней, сетевой карте шлюза.

Настройки будем производить с учетом наличия у нас статического (l2tp) ip — адреса. Можно использовать и динамический, но тогда каждый раз перед подключением придется сообщать его удаленному пользователю. Открывать доступ будем для определенной подсети / адреса и для программ, использующих в своей работе протокол rdp (3389).

Запускаем наш pfsense, переходим на страницу firewall — nat и во вкладке port forward добавляем новое правило нажатием кнопки с крестиком. В открывшемся окне, в блоке interface выбираем наш l2tp — интерфейс OPT1 (на этот интерфейс будет приходить внешний запрос). В блоке protocol указываем tcp.
Если у удаленного пользователя нет статического ip — адреса, то советую узнать диапазон этих адресов (адрес сети и ее маску), из которого они ему назначаются. Необходимо это для того, чтобы уменьшить количество ip — адресов потенциальных взломщиков.
После того, как мы узнали этот диапазон, в блоке source, в поле type указываем network (внешняя сеть), а в поле address — адрес внешней сети и ее маску, а в случае, если у пользователя имеется статический адрес, то указываем этот ip — адрес и его маску.
В блоке source port range указываем from — any и to — any.

Источник

Маршрутизация в pfSense. Проброс порта

Сетевые специалисты делят маршрутизаторы на два больших класса — программные и аппаратные. Аппаратные маршрутизаторы представляют оборудование разрабатываемое на предприятиях как готовый продукт. Программные реализации представляют собой набор программ или готовые сборки операционных систем, которые можно установить практически на любой современный компьютер или серверную платформу. Иногда бывает необходимо предоставить доступ из Интернета к машинам находящимся в локальной сети. Рассмотрим настройки маршрутизации — проброса портов (Port Forwarding) с помощью pfSense.

pfSense — это дистрибутив ПО основанный на ОС FreeBSD и предназначенный для организации маршрутизатора либо межсетевого экрана, либо все сразу . Данная ОС может быть установлена практически на любой компьютер или сервер. Ключевая особенность pfSense — решение поставленных задач через web-интерфейс.

Настройка сети

Если настройка выполняется через VPS/VDS, то следует создать все требуемые серверы, один из которых будет под управлением pfSense. Добавить сетевые адаптеры и объединить в в одну виртуальную сеть.

Приступаем к настройке

В основном меню программы (горизонтальное черное) выбираем Interfaces → Assignments.

Веб-страница обновится, появится список всех сетевых интерфейсов. “Свободные” интерфейсы находятся в поле Available network ports. Все интерфейсы показаны с mac-адресами на них. Из выпадающего списка выбираем необходимый и нажимаем кнопку “Add”.

После завершения действия, система уведомит об успешном добавлении. Интерфейс получит название “LAN”. Сохраняем настройки кликом по кнопке “Save”.

Настроим сетевой адаптер. Для этого в главном меню открываем Interfaces → LAN.

Установкой галки в поле Enable задействуем интерфейс. Установим настройку IPv4 как статичный IP (Static IPv4).

В секции настроек конфигурации “Static IPv4 Configuration” указываем IP-адрес для этого интерфейса, в нашем случае 10.0.0.254, возможно у вас будет другой. В самом низу страница нажимаем кнопку “Save” для сохранения внесенных изменений.

Система уведомит о внесенных изменениях. Применим их кликом по кнопке “Apply changes”.

Настроим сетевые интерфейсы клиентов

При настройке сетевых интерфейсов клиентов важно помнить, что адрес сервера pfSense должен быть указан в качестве шлюза, в нашем случае 10.0.0.254.

Настройка в Ubuntu

Редактируем файл /etc/network/interfaces:

iface ens31 inet static

Перезапускаем службу сети:

Windows

Для настройки сетевого адаптера в среде Windows необходимо открыть Пуск → Панель управления → Сеть и интернет → Сетевые подключения либо

Пуск → Панель управления → Сеть и интернет → Центр управления сетями и общим доступом → Изменение параметров адаптера.

В открывшейся папке кликаем правой кнопкой мыши по значку сетевого адаптера, выбираем “Свойства”.

В открывшемся окне кликом мыши по названию (не по галке) выбираем “Протокол Интернета версии 4 (TCP/IPv4)”. Нажимаем кнопку “Свойства”.

В новом окне указываем:

• IP-адрес — 10.0.0.3;
• Маска подсети: 255.255.255.0;
• Шлюз — 10.0.0.254;
• Предпочитаемый DNS-сервер: 8.8.8.8.

Для сохранения нажимаем кнопку “OK”. В окне Свойств сетевого адаптера также нажимаем кнопку “OK”.

Важно! Еще раз обращаем внимание, что IP-адрес сервера pfSense должен быть указан в качестве основного шлюза и шлюза по умолчанию.

Настроим маршрутизацию

В главном меню веб-приложения выбираем Firewall → NAT. На вкладке “Port Forward “. Нажимаем кнопку Add.

На открывшейся странице редактирования правила перенаправления трафика создадим правило для RDP-интерфейса.

В поле Destination указываем Any.

Destination port range (from port) — выбираем порт назначения, в нашем случае MS RDP. Поле “to port” заполнится автоматически.

Redirect target IP — указываем IP-адрес сервера или компьютера под управлением ОС Windows.

Redirect target port — MS RDP.

При желании заполняем поле описания — “Description”.

Нажимаем кнопку “Save”. И не забываем нажать кнопку “Apply changes”.

Важно! В случае если порт RDP был изменен (по умолчанию 3389), имя порта выбираем “Other”, в поле Custom указываем текущее значение.

Созданное правило отображается как в примере ниже.

Аналогичным способом создаются правила, скажем, для SSH-доступа.

Проверка подключения

Для проверки работоспособности настроек требуется подключиться SSH-клиентом или приложением для доступа к удаленному рабочему столу на внешний IP-адрес сервера pfSense.

Также, проверку можно выполнить с помощью сниффера сетевых портов — nmap.

Источник

Pfsense проброс портов не работает

Добрый день мне нужно пробросить порт 37777 на внутренний ip, firewall-nat, создаю правило интерфейс указываю, Destination интернет, Destination port range 37777, Redirect target IP нужный ip, Redirect target port 37777, Filter rule association выбираю создать новое правило, он создал его, но порт все равно недоступен…

Попробуйте правило создать firewall — rules — wan , а в firewal — nat правило автоматом создается.

Создал правило firevall-rules-wan, Source-wan address, Source port range-37777, Destination-внутренний Ip, Destination port range-37777, в nat правило не создается автоматический и порт не доступен.

Source — оставляем пусто (т.к. это откуда принимать входящие подключения, а у нас это WAN интерфейс)
Destination — пишем IP куда направить внутри локальной сети
Destination port range — 37777

Тема измусолена….
Думаю как обычно, у компьютера или DVR на который производится потрфарвард нет шлюза по умолчанию, либо пф не является для него шлюзом по умолчанию.

Да вот в том и проблема, я проверяю доступность портов с ПК(на ip которого проброс сделан) через сайт http://portscan.ru/, проброс и так по мануалу делаю, но ничего не выходит…

После обновления до версии 2.2 — появилась такая же проблема, pfsense стоит на виртуалке Proxmox. Проброшенные порты в версии 2.1.5 перестали работать в новой.
Просидел 3 часа….
Мне помогло System — Advanced — Networking. Поставить галку Disable hardware checksum offload и перезагрузить.

После обновления до версии 2.2 — появилась такая же проблема, pfsense стоит на виртуалке Proxmox. Проброшенные порты в версии 2.1.5 перестали работать в новой.
Просидел 3 часа….
Мне помогло System — Advanced — Networking. Поставить галку Disable hardware checksum offload и перезагрузить.

На каком железе у вас крутится proxmox ? CPU, chipset и (особенно) сетевые адаптеры?
И да, в кач-ве вирт. сетевых у вас virtio исп-ся ?

Источник

Pfsense проброс портов не работает

Доброго времени суток!
Задача: есть удаленный pfsense, на нём поднят openvpn и есть виндовый клиент с сервисами, на сенсе делаю проброс портов в тунель до клиента, не видит, если сделать redirect gateway тогда всё работает как надо, но весь трафик клиента идет через сенс,маршруты все нормальные. куда копать?нужно это для того, что на виндовом клиенте, не стабильный интернет и питание и люди переодически забирают сервер на другой адрес и соответственно сервисы недоступны!

Не совсем понятно , как у Вас настроена маршрутизация к удаленной сети
Если бы все было настроено корректно , весь трафик до удаленной сети по умолчанию уходил бы в туннель , без «танцев с бубном»

Или поясните на картинке , как у Вас все организовано

Здравствуйте! Думаю, у вас проблема, похожая на таковую в этой ветке

Тогда можно попробовать помимо port-forwarding’ов на IP в сетях C и D, еще и скрывать адрес источника подключения в сети интернет посредством Outbound NAT правила на Openvpn интерфейсе сервера — то есть все, что приходит из сети интернет (any) на такой-то порт таких-то IP в сетях C и D натить к IP адресу интерфейса openvpn сервера. У асусов на сторонах C и D есть маршрут к IP интерфейса openvpn сервера — так что трафик должен вернуться к серверу. Натиться будет не только адрес назначения, но и источника.

Добавлю, что интерфейс опенвпн на сервере должен быть назначен (assigned) и redirect-gateway, равно как и другие маршруты на клиенте больше не понадобятся, так как адреса источников всего трафика, приходящего через туннель по правилу порт-форвардинга, будут отнатированы к адресу опенвпн интерфейса, маршрут к которому виндовс клиент и так знает.

@Pupsoid
Зачем порт форвардинг в Вашем случае?
ТЗ полностью и с картинками давайте.

Источник

Pfsense проброс портов не работает

Коллеги, помогите решить задачу, пож-та.

Есть pfSense с публичным IP адресом, назовем его (A) и локальной подсетью (B)

На этом же pfSense работает OpenVPN сервер, к которому подключаются 2 разные сети (C & D) в качестве клиентов.

Маршрутизация работает отлично.

Клиенты с сети D имеют доступ как в сеть B, так и в сеть C.
Клиенты с сети C имеют доступ как в сеть B, так и в сеть D.
Из локальной подсети B все так же имеют доступ к сетям C & D.

Задача — организовать доступ (по http, например) к конкретному устройству в сети C или D через общий публичный ip адрес (A).

Создаю в NAT \ Port Forward правило переадресации на адрес в сети C или D, но что-то не работает.

Если создаю такое же правило переадресации на адрес в локальную подсеть (B), то все работает.

Куда стоит обратить внимание?
Спасибо!

Если сказать простыми словами, то есть:

1. pfSense с публичным ip адресом и настроенным OpenVPN сервером.
2. Сторонний маршрутизатор Asus с поддержкой SIM карты и OpenVPN клиента
3. DVR, подключенный к маршрутизатору Asus

Сотовые провайдеры публичные адреса как правило не дают, поэтому было принято решение организовать доступ к DVR через постоянно поднятое подключение Asus с pfSense по средствам OpenVPN, настроив к нему соответствующую маршрутизацию, через публичный ip адрес pfSense.

Добрый день! Мне кажется, дело в том, что пфсенсы на сторонах C и D не знают , куда надо маршрутизировать трафик обратно к адресу источника в сети интернет. У вас, скорее всего, интерфейсы openvpn на сторонах C и D не назначены в interfaces>assignments. Openvpn ( в отличие от IPsec VTI), умеет обратный трафик отправлять обратно в туннель благодаря reply-to в разрешающих правилах фаервола. Чтобы такое правило создалось, надо назначить ovpnc интерфейсы на пфсенсах C и D, и уже на этих интерфейсах создать разрешающие правила — вместо «OpenVPN» (тут правила надо удалить), который как бы виртуальная точка входа через опенвпн на фаерволе.

А, не обратил внимания на уточнение по железу опенвпн клиентов. Это Асусы, ок.

Тогда можно попробовать помимо port-forwarding’ов на IP в сетях C и D, еще и скрывать адрес источника подключения в сети интернет посредством Outbound NAT правила на Openvpn интерфейсе сервера — то есть все, что приходит из сети интернет (any) на такой-то порт таких-то IP в сетях C и D натить к IP адресу интерфейса openvpn сервера. У асусов на сторонах C и D есть маршрут к IP интерфейса openvpn сервера — так что трафик должен вернуться к серверу. Натиться будет не только адрес назначения, но и источника.

Спасибо, Владимир! Скорее всего вы правы! Что-то с обратным маршрутом. Настроил по описанной вами схеме, но «лыжи почему-то не поехали».

Распишу на конкретном примере с конкретными цифрами:

pfSense — имеет публичный статический адрес и локальную сеть 192.168.12.0/22
OpenVPN сервер работает со своей подсеткой 10.101.1.0/24

Asus 1 с OpenVPN клиентом и внутренней сеткой 10.70.10.0.24
(подключается к pfSense OpenVPN, получая адрес из 10.101.1.0/24)
Перенаправление всего трафика в VPN выключено

Asus 2 с OpenVPN клиентом и внутренней сеткой 10.80.10.0.24
(подключется к pfSense OpenVPN, получая адрес из 10.101.1.0/24)
Перенаправление всего трафика в VPN выключено

В сети Asus 2 есть устройство (на http) с адресом 10.80.10.100, к которому есть доступ со всех указанных сетей выше, однако при попытке настроить переадресацию и получить доступ снаружи — ничего не получается.

В NAT \ Outbound (установлен гибридный режим)
добавил Mapping —
Interface — OpenVPN
Source — any
Destination — Network 10.80.10.0 / 24

Translation
Здесь я пробовал Interface Address, публичный IP адрес и так же вручную вписывал адрес OpenVPN сервера — 10.101.1.1

Не работает.
Все ли я делаю правильно?

Вроде все правильно, но я бы все-таки назначил интерфейс openvpn server в interfaces> assignments > assign ovpnsX как например «OpenVPN_Server» и уже на нем бы делал outbound NAT трансляцию. Translation address лучше оставить как Interface Address. Потом попробуйте снова подключиться, выполняя параллельно команду в Diagnostics > Command Prompt shell > pfctl -ss | grep 10.80.10.100

Сделал на назначенном интерфейсе. Отказывается. Вот результат от pfctl:

( поменял ip сервера на x.x.x.x от греха 🙂

igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 SYN_SENT:CLOSED

Перезагрузка pfsense спасла положение! Все заработало! Спасибо!!

Отлично! По идее, должно работать после того, как pf обновит фильтры. То есть pfctl -ss показыват адрес источника, отнатившийся на openvpn_server интерфейсе?

Так точно! 10.101.1.1
Картина теперь в корне иная:

igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 FIN_WAIT_2:FIN_WAIT_2
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) 10.80.10.100:80 FIN_WAIT_2:FIN_WAIT_2

Еще раз спасибо!!

Касаемо ваших igbX https://docs.netgate.com/pfsense/en/latest/hardware/tuning-and-troubleshooting-network-cards.html

Роутер Asus? Padavan firmware или freshtomato firmware в гугле. Значительно свежее и интереснее стоковой firmware. Про openwrt как самый универсальный вариант напоминать не буду )

Всем привет !
У меня похожая проблема, на границе локальной сети стоит pfSense c VPN клиентом. При этом VPN не дает обратиться по публичному IP к веб серверу на том же хосте что и VPN сервер. Попробовал как написано выше — в interfaces>assignments добавил opvpnc1, доступ появился но лишь до перезагрузки pfSense или VPN-клиента . После перезагрузки доступа опять нет, пока опять не откроешь opvpnc1 и не нажмешь Save . В чем может быть засада ? И где вы смотрели логи на эту тему ?

Странно. Вы там случаем не весь трафик в ВПН заворачиваете?
Правила fw и таблицу марш-ции про поднятом ВПН покажите

Может и весь, у меня по дефолту сейчас все настройки, весь forwarding, что я пробовал не помог, я все правила удалил.
Я вычитал, что надо после создания ovpnc1 переподключить клиента, т.е. то, что он мне открывает доступ это видимо до переинициализации VPN-соединения, а после соединения VPN рубит весь http-трафик до сервера и видимо это штатное поведение . А как открыть доступ к web-серверам по обеим сторонам VPN ? Web-сервер доступен со всех прочих машин, которые не за VPN клиентом, т.е. web-сервер торчит в интернете по тому же ip что и VPN-сервер и всем доступен, т.е. на серверной стороне никаких проблем нет.

На самом pfSense порт сервера тоже доступен через VPN-адрес: Port test to host: 10.8.10.1 Port: 80 successful.

Но из локалки сайт не открывается ни по 10.8.10.1 ни по публичному IP.

Вот таблица при поднятом клиенте:

Destination Gateway Flags Use Mtu Netif Expire
default 192.168.8.1 UGS 3506 1500 hn0
10.8.10.1/32 10.8.10.5 UGS 0 1500 ovpnc1
10.8.10.5 link#7 UH 2123 1500 ovpnc1
10.8.10.6 link#7 UHS 0 16384 lo0
XX.XXX.XXX.XX/27 10.8.10.5 UGS 2254 1500 ovpnc1
127.0.0.1 link#2 UH 165 16384 lo0
192.168.1.0/24 link#6 U 20442 1500 hn1
192.168.1.1 link#6 UHS 0 16384 lo0
192.168.8.0/24 link#5 U 0 1500 hn0
192.168.8.1 00:15:5d:00:88:0e UHS 2164 1500 hn0
192.168.8.100 link#5 UHS 0 16384 lo0

Как то можно направить конкретный порт до интернет-узла мимо VPN ? По идее должно быть как-то тривиально .
Выставил статический маршрут XX.XXX.XXX.XX/27 -> WAN_DHCP — 192.168.8.1, вроде работает ! Такое решение вообще корректно ?

Выставил статический маршрут XX.XXX.XXX.XX/27 -> WAN_DHCP — 192.168.8.1, вроде работает ! Такое решение вообще корректно ?

Как коcтыль — вполне.

Зы. Так и не увидел скринов правил fw (

Зы2. Вижу, что пф живет на гипер-в (с VLAN в ВМ-ах на нем «поиграйтесь», ага). Блин, ну есть же xen, vmware, KVM. Чего это «чудо» пользовать-то для fw? Лень что-то новое изучать, видимо.

@werter
Можно сказать лень, а можно сказать «некогда». В hyper-v есть галочка «Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру.» Т.е. физическое соединение отдается под виртуалку, получается виртуальный шлюз межу интернетом и виртуалками. А пфсенс выбран за человеческий гуи, некогда читать толмуды и трах-ся с консолями, надо быстро решить конкретные и тривиальные задачи . а что это — fw ?

@Max69
Кстати обнаружился неприятный эффект — после обновления pfSense до 2.4.4 галочка «Разрешить управляющей операционной системе предоставлять общий доступ к этому сетевому адаптеру.» стала бесполезной. При запуске виртуалки c 2.4.4 сетевой адаптер становится доступным для хоста вне зависимости от галочки. Т.е. 2.4.4 не поддерживает эту фичу Hyper-V, и вообще локалка на прочих виртуалках пропала, короче обновление виртуального шлюза до 2.4.4 все ломает . пришлось откатить до 2.3.3 обратно. Надо будет в официальную техподдержку запросить, что за бред .

@Max69
Зевает
Обновите hyper-v. Какой там у вас последний-то? Об чем вопрос?
А, забыл. Это ж MS. Это ж целый гемор с мажорными обновлениями-то.
У меня это 3 (буквами — три) команды в shell (после правки sources):
apt-get clean; apt-get update; apt-get dist-upgrade -y

Можно сказать лень, а можно сказать «некогда».

Зы. Может тут чего docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-hyper-v.html
Или пишите в англоветке разрабам. Если это проблема пф, конечно.

@werter Не знаю какой гемор, винда обновляется автоматом . хочешь ставь все обновления, хочешь мажорные .
никакого гемора не было до обновления пф до 2.4.4

@werter А есть на других виртуальных платформах аналогичная возможность создать виртуальный шлюз на базе пф для виртуальной локальной сети. Если вы настолько против Hyper-V подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

Не знаю какой гемор, винда обновляется автоматом

Попробуйте обновить Hyper-v 2012 до 2019 )
И да. Гипер-в бывает разный — отдельный и КАК РОЛЬ сервера. У вас какой?

Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.

У PVE есть встроенный firewall c GUI. И без ВМ все можно гибко настроить. Мало того, этим же fw можно запретить\разрешить доступ к опред. портам\протоколам на самих VM. Для этого в настройках ВМ на сетевом интерфейсе есть галка Firewall.

Что такое PVE (и не только) forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-%D0%B8-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5-%D0%B2%D1%81%D0%B5

@werter
Клево, как нибудь обязательно испытаю это удовольствие .

Однако возвращаясь к вопросу, имею необходимость перенаправить порт с публичного IP через VPN туннель на локальную машину.
На клиенте сделал проброс: 10.0.8.2:8090->192.168.1.18090
На сервере делаю test port: 10.0.8.2 8090 Port test to host: 10.0.8.2 Port: 8090 successful. Т.е. сервер в интернете видит через VPN открытый порт на 192.168.1.1
Делаю на сервере проброс
Public IP:8090->10.0.8.2:8090, однако чрез Public IP соединения с веб-сервером нет. Что упускаю ?

Источник