Доступ к удаленной VPN через WAN pfSense (port forwarding)
-
А, не обратил внимания на уточнение по железу опенвпн клиентов. Это Асусы, ок.
Тогда можно попробовать помимо 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 подскажите альтернативу. Т.е. чтобы виртуалка закрывала физический сетевой порт порт даже для хоста.
-
@Max69 said in Доступ к удаленной VPN через WAN pfSense (port forwarding):
Не знаю какой гемор, винда обновляется автоматом
Попробуйте обновить 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 соединения с веб-сервером нет. Что упускаю ? -
Зачем на клиенте проброс?
Схему с адресацией в студию.
