Доступ к удаленной VPN через WAN pfSense (port forwarding)
-
Коллеги, помогите решить задачу, пож-та.
Есть 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), то все работает.
Куда стоит обратить внимание?
Спасибо! -
Если сказать простыми словами, то есть:
- pfSense с публичным ip адресом и настроенным OpenVPN сервером.
- Сторонний маршрутизатор Asus с поддержкой SIM карты и OpenVPN клиента
- 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 / 24Translation
Здесь я пробовал 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) <- 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 said in Доступ к удаленной VPN через WAN pfSense (port forwarding):
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) <- 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Еще раз спасибо!!
-
Касаемо ваших 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 Утащил в закладки.
-
Всем привет !
У меня похожая проблема, на границе локальной сети стоит pfSense c VPN клиентом. При этом VPN не дает обратиться по публичному IP к веб серверу на том же хосте что и VPN сервер. Попробовал как написано выше - в interfaces>assignments добавил opvpnc1, доступ появился но лишь до перезагрузки pfSense или VPN-клиента . После перезагрузки доступа опять нет, пока опять не откроешь opvpnc1 и не нажмешь Save ... В чем может быть засада ? И где вы смотрели логи на эту тему ? -
Добрый
@Max69Странно. Вы там случаем не весь трафик в ВПН заворачиваете?
Правила 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 подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.