OpenVPN PSK: Site-to-Site инструкция для обсуждения

rubic

Так в том то и дело, что трассировка с компа в сети филиала 1 на комп в сети филиала 2 - сразу же уходит к провайдеру, в то время, как трассировка с этого же компа на ком в сети центрального офиса - идет до адресата правильно. С компа центрального офиса, трассировка до компов филиалов тоже идет без нареканий.
По адресации - не совсем по rfc, понимаю. Но изменить пока возможности нет, но запланировано.

Из чего видно, что трассировка уходит к провайдеру? На pfSense 1-го филиала настроен какой-нибудь policy routing? Приведите скрин Firewall -> Rules -> LAN и Floating если в последнем что-то есть.

dsm150

Во всех трех PFS идентичные правила. На центральном только нет failover.

Каких то специальных правил не прописывал. Есть только портмаппинги по определенным портам, и все.

rubic

Выше правила FAILOVER сделайте правило:

Lan Net * 172.11.10.0/24 * * none

rubic

Во втором филиале тоже:

Lan Net * 172.11.11.0/24 * * none

swch

Спасибо за хорошую инструкцию.
Все сделал как в первой публикации и заработало, НО не все получилось. Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть?

rubic

@swch:

Спасибо за хорошую инструкцию.
Все сделал как в первой публикации и заработало, НО не все получилось. Из филиала сеть главного офиса пингуется и полностью доступна, а из центрального офиса сеть филиала не видна. Пинг не идет даже до адреса 10.0.8.2 (виртуальный адрес филиала). Трейсроут доходит до pfsens-а главного офиса и теряется. Что это может быть? В какую сторону рыть?

Смотрите в сторону правил файервола на LAN центрального офиса. Простейший способ проверить, что дело в них - временно разрешить все.

swch

Так в том то и дело, что в ЛАНе практически все разрешено, кроме 80 порта. Что б люди ходили через прокси, а не через NAT. В таблице маршрутизации тоже криминала не вижу. Грешу на обновление до версии 2.1. Похоже надо перебивать сервак, а очень не хочется.

werter

2 swch

Покажите таблицу маршрутизации и что стоит на втором конце туннеля?

swch

Сегодня выяснилась странная ситуация. Оказывается сеть главного офиса доступна, просто пинг не ходит. Но правила блокирующего протокол ICMP я не создавал. Чертовщина какая-то!
Вопрос закрыт.

xojic

Попробуй прописать основной шлюз pfsense, на той тачке которую хочешь пингануть.

pigbrother

@rubic:

Пока объяснял уже сам все понял. Дела… Сегодня заставил наконец бегать OSPF по OpenVPN между работой и домашним микротиком. Полгода назад неделю на это убил безрезультатно. Пришлось править quagga_ospfd.inc

Спасибо за статью и ответы по теме.

В удаленном офисе появился появился микротик, хочется задействовать данную инструкцию, подключив микротик вместо pfsense в удаленном офисе (без OSPF)
Микротик будет находится за NAT.

Отсюда вопросы.

1.Достаточно ли будет задействовать на микротике open-vpn клиент?
2. Если да, то как сказать микротикe пускать в локальную сеть за собой?
3.Где указать микротику использовать Shared key?

werter

http://nix.khd.ru/?p=1373

http://nixman.info/?p=1379

Ну и http://wiki.mikrotik.com/wiki/OpenVPN

P.s. Все таки это не профильный форум Микротика. И да, учитесь использовать поиск.

vsop1

Добрый день! При реализации данной схемы есть проблема. Пинг проходит только на LAN адреса. Т.е. есть две подсетки 192.168.28.0/24 и 192.168.1.0/24 между ними OpenVPN пинг проходит только на LAN адреса pfsense. На *28.15 из подсетки *1.0 и на *1.1 из подсетки *28.0. Установлен последний pfsense.

werter

Директивы iroute , route .

P.s. Покажите настройки клиента, сервера и правил fw (LAN, OpenVPN) на них же.

vsop1

Прошу прощения за беспокойство. Сам накосячил - сам разобрался)

N3w4dm1n

на главном сенсе поднял сервер опенвпн 10.8.0.0/24 ->192.168.1.0/24, на клиенте так же все соответственно прописал как в инструкции с preshared key. но вот достучаться до главного офиса не могу. зависает на процессе connect to server IP.

надо ли в дополнительной конфиге прописывать правило хождения через сеть ван -> интернет -> главный офис?

KARLAGIN

Еще одни грабельки вырисовались. Имеем сеть из главного офиса и 10 удаленных, настроен OpenVPN все работает. Но имеем IP телефонию. Аппараты из удаленных филиалов стучатся на главный сервер ip телефонии в офисе по порту 5060. 90 случаев из ста все проходит хорошо, но в 10 случаях аппараты подключаются к атс по непонятным портам из разряда 1040-1050. В чем может быть загвоздка, можно ли в данном случае прописать что при обращении к 5060 он жестко передавался на 5060?

pigbrother

@N3w4dm1n:

на главном сенсе поднял сервер опенвпн 10.8.0.0/24 ->192.168.1.0/24, на клиенте так же все соответственно прописал как в инструкции с preshared key. но вот достучаться до главного офиса не могу. зависает на процессе connect to server IP.
надо ли в дополнительной конфиге прописывать правило хождения через сеть ван -> интернет -> главный офис?

Для начала:
Имеет ли сервер "белый" IP на WAN?
Если да, есть ли на WAN правило вида
TCP/UDP * * WAN address 1194 * none OVPN servers incoming rule

Где 1194 - порт, на который вы повесили OVPN-сервера
TCP или UDP выбирать, исходя из настроек сервере

НО:
Если WAN Получает IP вида 192.х.х.х. 10.х.х.х 172.16.х.х подключение о стороны WAN к такому серверу невозможно (либо потребуется пробрасывать порт со стороны провайдера)

Menog

сделал все как в первом посте
гл. офис - PfsenseServer - 192.168.2.0/24
филиал - PfsenseClient - 192.168.4.0/24
OVPN Tunneling - 192.168.8.0/24

В итоге
с самого PfsenseClientа видна вся подсеть 192.168.2.0/24, НО с компьютеров филиала под PfsenseClientом ничего не видно и не пингуется
с PfsenseServerа не пингуется PfsenseClient, и, соответственно с компьютеров под PfsenseServerом тоже….

Tracert 192.168.4.1 from PfsenseServer

Traceroute output:
1 * * *
2 * * *
3 * * *

Tracert 192.168.2.1 с компьютера филиала под PfsenseClientом

Traceroute output:
1 * * *
2 * * *
3 * * *

Tracert 192.168.2.1 с PfsenseClientа (что самое странное, т.к. 192.168.2.1, как и вся подсеть 192.168.2.0/24 нормально с него пингуется....)

Traceroute output:
1 * * *
2 * * *
3 *

Pfsense version 2.1.5

настройки Firewall идентичны, так что прилагаю скриншоты только с PfsenseServer

ovpn_server_client.png_thumb

ovpn_server.png_thumb
ovpn_client.png_thumb

ovpn_server_LAN.png_thumb

ovpn_server_WAN.png_thumb

ovpn_server_OVPN.png_thumb

ovpn_client_Routes.png_thumb

ovpn_server_Routes.png_thumb

werter

Что указано в кач-ве адреса шлюза на машинах за сервером и клиентом в их сетевых настройках ? Проверьте этот момент.

Далее, для того чтобы машины ЗА сервером увидели машины ЗА клиентом, необходимо, чтобы в настройках сервера во вкладке Client Specific Overrides присутствовала директива iroute - iroute 192.168.4.0 255.255.255.0;

И проверяйте traceroute доступность машин ЗА сервером\клиентом, а не адреса pfsense на обоих концах.

Совет. Смените с режим OpenVPN c P2P на Remote Access (SSL/TLS) - https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server