Доступ к удаленной 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), то все работает.

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



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

    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 сервера - так что трафик должен вернуться к серверу. Натиться будет не только адрес назначения, но и источника.



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

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

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

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

    3. 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) <- 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

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



  • @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 Утащил в закладки.


Log in to reply