PfSense OpenVPN Server + Linux-client

Tano

@werter:

Если для клиента не использовать OpenVPN Client specific overrides то как я передам клиенту информацию об удаленной сети, в этом случае клиент получит доступ только в главную сеть, который по сути сейчас и имеет, но у него не появится маршрут в удаленную сеть.

Вы ошибаетесь. Client specific overrides исп-ся для сети за сервером для доступа к сети за клиентом.
Для доступа к сети за сервером клиенту сервером отдаются марш-ты директивой push route …..;

Спасибо за подсказку, я забыл про этот момент.
Сейчас доеду до удобного места и поэкспериментирую.

Общее замечание:
По поводу Client specific overrides я настраивал OPEN VPN режим Remote access SSL/TSL все по этой "ИНСТРУКЦИИ https://forum.pfsense.org/index.php?topic=99694.0"
Там как раз мобильному клиенту (по аналогии с удаленным шлюзом) настраивается Client specific overrides, вот я и посчитал, что основная цель этого раздела для передачи маршрутов, а оказалось, что в действительности все маршруты может дать сервер, и лишь если надо конкретному клиенту создать особые правила, можно/нужно применить Client specific overrides для этого клиента.

В моём случае:
Теперь удалил по вашим советам все Client specific overrides кроме одного, который для роутера, где и нужно обеспечить двухсторониий обмен данными и чтобы все машины за сервером и за роутером могли обмениваться данными друг с другом. Сейчас это реализовано, обмен есть.
Роутер получает инструкцию от сервера и поднимает два маршрута в главную сеть, у меня их две сети LAN, в итоге он впускает и выпускает пакеты из/в главной сети.
При подключении мобильного клиента, он получает все инструкции от сервера, в том числе три маршрута и один из них в сеть …87.0/24, без использования Client specific overrides, однако доступа в удаленную сеть 192.168.87.0/24 нет.
Затык идет на pfsense, он не заворачивает запрос из туннеля openvpn мобильного клиента в туннель между pfsense-роутер.
В FW OPENVPN правило Pv4 * * * * * * none
В FW LAN правило IPv4 * LAN net * 192.168.87.0/24 * * none
Floating ничего нет
WAN открыт нужные порты иначе не было бы соединения.
OutBound WAN 127.0.0.0/8 192.168.1.0/24 192.168.12.0/24 192.168.1.80/32 10.0.0.0/24 10.87.0.0/24 10.12.0.0/24 * * * WAN address * NO

timon12

Главное не бояться экспериментов, так и учимся.
Отлично, ковыряем дальше NAT или Firewall-rules

При подключении мобильного клиента, он получает все инструкции от сервера, в том числе три маршрута и один из них в сеть …87.0/24, без использования Client specific overrides, однако доступа в удаленную сеть 192.168.87.0/24 нет.
Затык идет на pfsense, он не заворачивает запрос из туннеля openvpn мобильного клиента в туннель между pfsense-роутер.
В FW OPENVPN правило Pv4 * * * * * * none
В FW LAN правило IPv4 * LAN net * 192.168.87.0/24 * * none

Обратно же, для понимания в чем затык, предлагаю поставить первым правило
В FW LAN правило IPv4 * * * 192.168.87.0/24 * * none

Делаем трасерт на .87.0\24 с мобильго клиента, ложим скрин на форум.

Если проблема в этом, тогда изменим на (но только тогда)
В FW LAN правило IPv4 * VPN mobile net * 192.168.87.0/24 * * none

Если проблема не решена, пишем на форум и думаем дальше.
И забегая наперед, покажите таблицу маршрутизации вашего удаленного роутера, интересует вопрос, знает ли он, где ваша сеть для мобильных клиентов (в идеале должен знать, когда подключился по впн к ПФ-ке в центральном офисе)

Теперь удалил по вашим советам все Client specific overrides кроме одного, который для роутера

Этот момент смущает немного, но вначале разберемся с заворотом трафика из впн в впн. Там парочка отдельных вопросов.

Tano

timon12
Спасибо за помощь.
Правило было первым, добавил еще два правила с туннелями, как вы предложили, два потому, что у меня два туннеля.
Выложил скрин FW LAN.
Все равно трасерт не проходит, так же как не проходил без этих дополнительных правил.
Скрины во вложении, в том числе и таблица маршрутизации на удаленном роутере.

![Route print client_sony1.PNG](/public/imported_attachments/1/Route print client_sony1.PNG)
![Route print client_sony1.PNG_thumb](/public/imported_attachments/1/Route print client_sony1.PNG_thumb)
![Tracert1 from client to 87net.PNG](/public/imported_attachments/1/Tracert1 from client to 87net.PNG)
![Tracert1 from client to 87net.PNG_thumb](/public/imported_attachments/1/Tracert1 from client to 87net.PNG_thumb)
![Routes-tomato router1.JPG](/public/imported_attachments/1/Routes-tomato router1.JPG)
![Routes-tomato router1.JPG_thumb](/public/imported_attachments/1/Routes-tomato router1.JPG_thumb)
![FW LAN.JPG](/public/imported_attachments/1/FW LAN.JPG)
![FW LAN.JPG_thumb](/public/imported_attachments/1/FW LAN.JPG_thumb)

werter

Последний скрин.
На LAN работают правила, относящиеся только к LAN. Никакие др. запреты\разрешения , касающиеся др. сетей не работают.
Так что всякие там 10.x.x.x и т.д. , если это на virtual ip LAN, работать не будут. Откл. их.

timon12

На LAN работают правила, относящиеся только к LAN.

Тоже верно, но на всякий случай проверить стоило, мое мнение.

Tano!
На скрине Routes-tomato router1.JPG нет маршрута к сети мобильных клиентов, по идее пф-ка должна была выдать томато еще и такой маршрут (при поднятии коннекта между офисами):
Destination Gateway Subnet Metric Inteface

192.168.1.0 10.87.0.5 /24 0 tun11 - этот маршрут у томато есть
10.0.0.0 10.87.0.5 /24 0 tun11 - а вот этого не хватает

Как вариант, можно дописать в настройках "впн-сервера между офисами" Tunnel Settings -> IPv4 Local Network/s - сеть мобильных клиетнов (10.0.0.0\24), или в client cpecific overrides (что менее практично, и для томато я бы тоже удалил настройки в client cpecific overrides)

pigbrother

Потерял сюжетную линию саги pfSense OpenVPN Server + Linux-client.

Возможно - не к месту, но в свое время столкнулся с тем, что OVPN-клиент Микротик при работе c pfSense упорно не получал маршруты в удаленные OpenVPN сети.
Помогло явное указание шлюза в Client Specific Overrides, т.е.
push route "xx.0.3.0 255.255.255.0 10.11.12.1";push route "xx.0.5.0 255.255.255.0 10.11.12.1";
где 10.11.12.1 - "серверный" IP туннеля.

либо статическое прописывание этого шлюза в клиенте.

timon12

pigbrother!
Ход мыслей у вас правильный, а вот где прописывать настройки это уже зависит от того кого с кем надо "скрещивать".
Был и у меня "брачный период pfsense+mikrotik", в итоге mikrotik остался как пограничный шлюз (випиэнами подружились, а вот скорость коннекта с шифрованием не вытащил на минимально необходимую), вопрос решился установкой пф-ки с впнэнами как виртуальную.

pigbrother

Минимально необходимая - это сколько?

Основная нагрузка туннелей у меня - RDP, ему много не надо. Тестировал и передачей больших файлов. Максимально удавалось получать прибл. 15 мегабит, причем узким местом был\есть и слабенький процессор на машине с pfSense.

werter

2 pigbrother

Попробуйте в конфиг OpenVPN-сервера в Advanced добавить :

sndbuf 100000;
rcvbuf 100000;
push "sndbuf 100000";
push "rcvbuf 100000";

После, переподкл. клиентом и проверить скорость передачи в туннеле. Есть вариант, что она вас удивит.

Tano

@timon12:

На LAN работают правила, относящиеся только к LAN.

Тоже верно, но на всякий случай проверить стоило, мое мнение.

Tano!
На скрине Routes-tomato router1.JPG нет маршрута к сети мобильных клиентов, по идее пф-ка должна была выдать томато еще и такой маршрут (при поднятии коннекта между офисами):
Destination Gateway Subnet Metric Inteface

192.168.1.0 10.87.0.5 /24 0 tun11 - этот маршрут у томато есть
10.0.0.0 10.87.0.5 /24 0 tun11 - а вот этого не хватает

Как вариант, можно дописать в настройках "впн-сервера между офисами" Tunnel Settings -> IPv4 Local Network/s - сеть мобильных клиетнов (10.0.0.0\24), или в client cpecific overrides (что менее практично, и для томато я бы тоже удалил настройки в client cpecific overrides)

Поскольку мне нужно организовать двухстороний обмен я решил пока оставить client cpecific overrides для роутера и в поле IPv4 Local Network/s добавил 10.0.0.0\24, перегрузил канал, роутер получил еще одно правило - 10.0.0.0 10.87.0.5 255.255.255.0 0 tun11
Из FW LAN убрал два ненужных правила.
Проверить что изменилось смогу только ближе к вечеру.
Но как мне кажется проблема именно на PFSENSE, поскольку на ней тормозится трасировка и нет переброски пакетов из сети 10.0.0.0\24 в сеть 10.87.0.0/24

timon12

Минимально необходимая - это сколько?

На связке pfsense + mikrotik в OpenVPN удалось выжать (iperf) 300 Mbits/sec в обе стороны.
На связке pfsense + pfsense (iperf) выжымаю 500 Mbits/sec с удаленного офиса, и 750 Mbits/sec на удаленный офис.
Зачем "такое" - требования руководства.
А вот почему скорость не синхронная, я бы тоже хотел знать. Но данный топик не по теме микротика.

2 pigbrother

Попробуйте в конфиг OpenVPN-сервера в Advanced добавить :

sndbuf 100000;
rcvbuf 100000;
push "sndbuf 100000";
push "rcvbuf 100000";

После, переподкл. клиентом и проверить скорость передачи в туннеле. Есть вариант, что она вас удивит.

Благодарю за совет!
Попробуем, есть еще тренировочные микротики.
Вот, может кому и пригодиться "для брачных контрактов разных систем":
https://habrahabr.ru/post/246953/
И в довесок:
https://community.openvpn.net/openvpn/ticket/461
https://github.com/OpenVPN/openvpn/blob/859f6aaac6ef35c54306b6f10d2ec902dd41c89b/src/openvpn/socket.h#L47

pigbrother

После, переподкл. клиентом и проверить скорость передачи в туннеле. Есть вариант, что она вас удивит.

Проверю вечером, отпишусь.

timon12

Tano!

Но как мне кажется проблема именно на PFSENSE, поскольку на ней тормозится трасировка и нет переброски пакетов из сети 10.0.0.0\24 в сеть 10.87.0.0/24

Если в Firewall -> Rules -> OpenVPN есть
IPv4 * * * * * * none

То в теории проблем не должно быть

werter

2 timon12

Вот, может кому и пригодиться "для брачных контрактов разных систем":
https://habrahabr.ru/post/246953/

Этой статьей и руководствовался.

P.s. OpenVPN one-click install - https://habrahabr.ru/company/infobox/blog/248445/ Проверил - работает.

timon12

2 werter

P.s. OpenVPN one-click install - https://habrahabr.ru/company/infobox/blog/248445/ Проверил - работает.

Благодарю. Попробую.

pigbrother

@pigbrother:

После, переподкл. клиентом и проверить скорость передачи в туннеле. Есть вариант, что она вас удивит.

Проверю вечером, отпишусь.

Да, скорость ощутимо выросла. Процессор при этом ожидаемо нагружается не меньше, скорее даже еще сильнее.
Чтож, хотите скоростей - не жалейте заварки ;)
Читал, что с выходом OpenVPN 3.0 появится поддержка AES-NI.
https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B5%D0%BD%D0%B8%D0%B5_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4_AES
Авторы pfSense обещают полную поддержку для IPsec и, частичную, для OpenVPN

Tano

Я типа упертый и хочу все же настроить и хочу научиться настраивать openvpn.
Теории уже много начитался и ранее и за этот топик.
Начал с того, что отключил openvpn сервер Peer to peer ssl/tls.
Оставил только openvpn Remote access SSL/TLS, подключил к нему роутер на прошивке TOMATO shibby v.133
Роутер получил маршруты в главную сеть - lan - 192.168.1.0/24 и во вторую lan 192.168.12.0/24.
Из сети за роутером все машины могут обращаться к ресурсам главной сети, типа RDP на терминальный сервер или NAS.
Из главной сети НЕТ доступа в сеть за роутером.
Client specific overrides для роутера указываю в
IPv4 Local Network/s - 192.168.1.0/24, 192.168.12.0/24
IPv4 Remote Network/s - 192.168.87.0/24
Для пущей страсти там же в Advanced - iroute 192.168.87.0 255.255.255.0;
Но в таблице маршрутов PFSENSE только вот такие маршруты связанные с OVPNS2
IPv4
Destination Gateway Flags Use Mtu Netif Expire
default 10.78.112.1 UGS 1423882 1500 em1
10.78.112.0/21 link#2 U 79994 1500 em1
10.78.113.65 link#2 UHS 0 16384 lo0
12.0.0.0/24 12.0.0.2 UGS 1586 1500 ovpns2
12.0.0.1 link#10 UHS 0 16384 lo0
12.0.0.2 link#10 UH 0 1500 ovpns2
127.0.0.1 link#6 UH 3166 16384 lo0
172.16.1.40 00:0c:29:b8:e3:82 UHS 23760 1500 em1
172.16.1.41 00:0c:29:b8:e3:82 UHS 23778 1500 em1
192.168.1.0/24 link#1 U 1425318 1500 em0
192.168.1.1 link#1 UHS 0 16384 lo0
192.168.12.0/24 link#3 U 21357 1500 em2
192.168.12.1 link#3 UHS 0 16384 lo0

Что у меня не так? Почему не поднимается маршрут в сеть 192.168.87.0/24 через туннель 12.0.0.0/24
Такой маршрут у меня автоматом появляется только если я создаю сервер по типу Peer to peer SSL/TLS, который я временно для эксперимента отключил, как написал в начале.

timon12

@Tano:

@timon12:

На LAN работают правила, относящиеся только к LAN.

Тоже верно, но на всякий случай проверить стоило, мое мнение.

Tano!
На скрине Routes-tomato router1.JPG нет маршрута к сети мобильных клиентов, по идее пф-ка должна была выдать томато еще и такой маршрут (при поднятии коннекта между офисами):
Destination Gateway Subnet Metric Inteface

192.168.1.0 10.87.0.5 /24 0 tun11 - этот маршрут у томато есть
10.0.0.0 10.87.0.5 /24 0 tun11 - а вот этого не хватает

Как вариант, можно дописать в настройках "впн-сервера между офисами" Tunnel Settings -> IPv4 Local Network/s - сеть мобильных клиетнов (10.0.0.0\24), или в client cpecific overrides (что менее практично, и для томато я бы тоже удалил настройки в client cpecific overrides)

Поскольку мне нужно организовать двухстороний обмен я решил пока оставить client cpecific overrides для роутера и в поле IPv4 Local Network/s добавил 10.0.0.0\24, перегрузил канал, роутер получил еще одно правило - 10.0.0.0 10.87.0.5 255.255.255.0 0 tun11
Из FW LAN убрал два ненужных правила.
Проверить что изменилось смогу только ближе к вечеру.
Но как мне кажется проблема именно на PFSENSE, поскольку на ней тормозится трасировка и нет переброски пакетов из сети 10.0.0.0\24 в сеть 10.87.0.0/24

Для справки - проверяли или нет?

Tano

@timon12:

Для справки - проверяли или нет?

Да проверял, не помогло, поэтом решил радикально поступить и типа с начала начать.
Кстати вот 5 минут назад удалось соединить две сети, в режиме remote accesse SSL/TLS. Ура, есть обмен данными в обе стороны.
Завелось это все у меня только с такими настройками:
на сервере IPv4 Local Network/s 192.168.1.0/24, 192.168.12.0/24
и в Advanced
route 192.168.87.0 255.255.255.0; - это для сервера
push "route 192.168.87.0 255.255.255.0"; - это для других мобильных клиентов.
а в client specifi для роутера
Tunnel Network - пусто.
IPv4 Local Network/s 192.168.1.0/24, 192.168.12.0/24
IPv4 Remote Network/s 192.168.87.0/24
и в Advanced
iroute 192.168.87.0. 255.255.255.0
Server Definitions Prevent this client from receiving any server-defined client settings. - НЕ УСТАНОВЛЕНА

Теперь только мобильные клиенты не могут получить доступ в удаленную сеть, а в главную имеют, хотя маршрут в удаленную сеть мобильный клиент получил.
имеем следующий затык, мобильный клинет получив маршрут в сеть 87.0/24 отправляет пакеты в туннель 12.0.0.0/24
после 12.0.0.1 ступор, а это согласно NET30 адрес PFSENSE вот тут красиво все разрисовано https://forum.pfsense.org/index.php?topic=59081.msg317265#msg317265.
Что куда дописать?

timon12

Разница между режимами работы только в количестве настроек - по большому счету
Попробуйте от обратного - с удаленного офиса увидеть мобильного клиента - при этом подтяните еще и знания по маршрутизации
Если уж совсем не прокатит то отпишитесь - предоставлю свою схему работы под ваш вариант офиса-оборудования
Как по мне - то надо тренировать ТОМАТО и при этом практически все настройки чтоб отдавал ему pfsense, со всей необходимой маршрутизацией. Как делать - было выше но на микротиках.
На ссылке, что указали, там Peer-to-Peer а не Remoute Access, и плюс там pfsense+pfsense, а у вас pfsense+tomato