PfSense OpenVPN Server + Linux-client

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

Tano

@timon12:

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

Все победа, в этот раз надо было лишь включить на сервере галку на разрешение обмена данными между подключенными клиентами.
Большое всем спасибо.
Следующий этап это подключение еще одной удаленной сети, на базе еще одного роутера, думаю опять на томато, поскольку на zyxel как то все мудрено получается и организация связи между всеми участниками.