Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PfSense OpenVPN Server + Linux-client

    Scheduled Pinned Locked Moved Russian
    76 Posts 5 Posters 15.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      pigbrother
      last edited by

      @Electric^shock:

      tap или tun? Если Site-to-Site?

      tun - для маршрутизации между разными сетями. tap - объединения сетей в одну L2\Ethernet-сеть, как будто у сетей один свитч.
      https://ru.wikipedia.org/wiki/TUN/TAP

      1 Reply Last reply Reply Quote 0
      • T
        Tano
        last edited by

        @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

        1 Reply Last reply Reply Quote 0
        • T
          timon12
          last edited by

          Главное не бояться экспериментов, так и учимся.
          Отлично, ковыряем дальше 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 кроме одного, который для роутера

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

          1 Reply Last reply Reply Quote 0
          • T
            Tano
            last edited by

            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)

            1 Reply Last reply Reply Quote 0
            • werterW
              werter
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • T
                timon12
                last edited by

                На 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)

                1 Reply Last reply Reply Quote 0
                • P
                  pigbrother
                  last edited by

                  Потерял сюжетную линию саги 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 туннеля.

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

                  1 Reply Last reply Reply Quote 0
                  • T
                    timon12
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • P
                      pigbrother
                      last edited by

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

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

                      1 Reply Last reply Reply Quote 0
                      • werterW
                        werter
                        last edited by

                        2 pigbrother

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

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

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

                        1 Reply Last reply Reply Quote 0
                        • T
                          Tano
                          last edited by

                          @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

                          1 Reply Last reply Reply Quote 0
                          • T
                            timon12
                            last edited by

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

                            На связке 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

                            1 Reply Last reply Reply Quote 0
                            • P
                              pigbrother
                              last edited by

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

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

                              1 Reply Last reply Reply Quote 0
                              • T
                                timon12
                                last edited by

                                Tano!

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

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

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

                                1 Reply Last reply Reply Quote 0
                                • werterW
                                  werter
                                  last edited by

                                  2 timon12

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

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

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

                                  1 Reply Last reply Reply Quote 0
                                  • T
                                    timon12
                                    last edited by

                                    2 werter

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

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

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      pigbrother
                                      last edited by

                                      @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

                                      1 Reply Last reply Reply Quote 0
                                      • T
                                        Tano
                                        last edited by

                                        Я типа упертый и хочу все же настроить  и хочу научиться настраивать 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, который я временно для эксперимента отключил, как написал в начале.

                                        1 Reply Last reply Reply Quote 0
                                        • T
                                          timon12
                                          last edited by

                                          @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

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

                                          1 Reply Last reply Reply Quote 0
                                          • T
                                            Tano
                                            last edited by

                                            @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.
                                            Что куда дописать?

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.