Доступ к удаленной VPN через WAN pfSense (port forwarding)

Plaokom

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

Есть 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), то все работает.

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

Plaokom

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

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

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

vladimirlind

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

vladimirlind

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

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

Plaokom

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

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

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

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

vladimirlind

Вроде все правильно, но я бы все-таки назначил интерфейс 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

Plaokom

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

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

igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 217.66.158.63:36956 CLOSED:SYN_SENT
igb0 tcp 217.66.158.63:36956 -> 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 217.66.158.63:2334 CLOSED:SYN_SENT
igb0 tcp 217.66.158.63:2334 -> 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 185.176.27.42:54487 CLOSED:SYN_SENT
igb0 tcp 185.176.27.42:54487 -> 10.80.10.100:80 SYN_SENT:CLOSED
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 217.66.158.63:16013 CLOSED:SYN_SENT
igb0 tcp 217.66.158.63:16013 -> 10.80.10.100:80 SYN_SENT:CLOSED

Plaokom

@Plaokom said in Доступ к удаленной VPN через WAN pfSense (port forwarding):

SYN_SENT:CLOSED

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

vladimirlind

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

Plaokom

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

igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 217.66.158.63:10677 FIN_WAIT_2:FIN_WAIT_2
ovpns1 tcp 10.101.1.1:3848 (217.66.158.63:10677) -> 10.80.10.100:80 FIN_WAIT_2:FIN_WAIT_2
igb0 tcp 10.80.10.100:80 (x.x.x.x:80) <- 217.66.158.63:34202 FIN_WAIT_2:FIN_WAIT_2
ovpns1 tcp 10.101.1.1:9853 (217.66.158.63:34202) -> 10.80.10.100:80 FIN_WAIT_2:FIN_WAIT_2

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

werter

@Plaokom

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

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

Ps. Тема эта часто всплывает. А тут - готовое решение ) Спасибо @Plaokom и @vladimirlind Утащил в закладки.

Max69

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

werter

Добрый
@Max69

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

Max69

Может и весь, у меня по дефолту сейчас все настройки, весь 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, вроде работает ! Такое решение вообще корректно ?

werter

@Max69

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

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

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

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

Max69

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

Max69

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

werter

@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
Или пишите в англоветке разрабам. Если это проблема пф, конечно.

Max69

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

Max69

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