Navigation

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

    2wan ipsec failover

    Russian
    2
    10
    2852
    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.
    • A
      aekvulture last edited by

      Есть 2 площадки. На каждой по 2 провайдера. Между площадками поднят ipsec туннель. Сейчас каждой стороны стоит по cisco 1811 каждая из которых с любого из своих 2-х портов может "дозвониться" до любого из 2-х портов другой циски. Т.е. с каждой стороны может упасть любой из 2-х провайдеров, туннель всё-равно будет жить. Можно ли реализовать такую же схему с помощью 2-х pfSense ?

      PS: Находил старые топики по этому вопросу, но там так ни к чему и не пришли. Может с новой версией что-то поменялось.

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

        Хммм, как бы вот - https://doc.pfsense.org/index.php/2.1_New_Features_and_Changes :

        IPsec multi-WAN failover

        P.s. Вот еще - http://serverfault.com/questions/487684/ipsec-l2l-failover-between-two-pfsense-devices :

        Q. Is it possible to achieve IPSec L2L failover (ie, from one WAN interface to another) between two pfSense devices using Gateway Groups, or really anything other than defining multiple IPSec connections on both ends and disabling/enabling them manually as needed?

        A. 2.1 can do a gateway group on IPsec. Earlier versions require manual intervention for tunnel mode IPsec. Transport mode + a tunnel + a routing protocol, or more easily OpenVPN+a routing protocol, can accommodate that in all 2.x versions.

        Т.е. создаете группу из своих внешних интерфейсов и в настройках fw (во вкладке IPsec) указываете эту группу в кач-ве шлюза.

        Если получится - отпишите с картинками, пожалуйста. Многим пригодится.

        1 Reply Last reply Reply Quote 0
        • A
          aekvulture last edited by

          Спасибо, с этим разобрался. Однако осталась ещё одна непонятка, в настройках IPSEC можно указать только один Remote gateway, а мне нужно указать 2. В циске я просто вбивал пиры один за одним сколько хочешь и она их перебирала при недоступности. Тут конечно можно выйти из положения с помощью DynDNS и в качестве пира указать DNS имя, но зависеть от стороннего сервиса не хотелось бы.

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

            @aekvulture:

            Спасибо, с этим разобрался. Однако осталась ещё одна непонятка, в настройках IPSEC можно указать только один Remote gateway, а мне нужно указать 2. В циске я просто вбивал пиры один за одним сколько хочешь и она их перебирала при недоступности. Тут конечно можно выйти из положения с помощью DynDNS и в качестве пира указать DNS имя, но зависеть от стороннего сервиса не хотелось бы.

            Вы создаете два IPSec соединения, указав в VPN: IPsec: Edit Phase 1: Interface сперва WAN1 и remote gateway 1, потом - WAN2 и remote gateway2. Потом создаете из них gateway group (?) и уже его используете в настройках. Надо проверять это дело.

            К сожалению, я лично не могу повторить  - у меня нет ни двух WAN-ов да и версия pfsense у меня 2.0.3  :'(

            P.s. Или вариант 2 :

            • создаете gateway group из Ваших WAN1 и WAN2
            • этот gateway group используете в VPN: IPsec: Edit Phase 1: Interface - если такое на 2.1 возможно
            1 Reply Last reply Reply Quote 0
            • A
              aekvulture last edited by

              Так как вы описали не получится. В реальности всё выглядит так: System -> Routing -> Groups -> Тут создаём группу из 2-х Gateway -> GWGroup1 (пока был один WAN группа не создавалась). Тут же в настройках группы указываем как должны себя вести шлюзы внутри группы - выставить вес каждого из них или сделать балансировку, как определять падение шлюза в группе и т.д. Потом я создаю одно IPSec соединение и в поле Interface указываю не WAN, а GWGroup1. Вроде бы всё прикольно, но блин, надо вбить 2 хоста в Remote gateway, чтобы туннель мог постучаться на другой интерфейс удалённого роутера при падении первого интерфейса.

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

                Т.е. это описанный мною вариант 2 получается.

                Вроде бы всё прикольно, но блин, надо вбить 2 хоста в Remote gateway, чтобы туннель мог постучаться на другой интерфейс удалённого роутера при падении первого интерфейса.

                Выше описал как попробовать . С поправкой на интерфейсы (используйте ваш GWGroup) пробуйте :

                Вы создаете два IPSec соединения, указав в VPN: IPsec: Edit Phase 1: Interface сперва GWGroup и remote gateway 1, потом - GWGroup и remote gateway2

                Только вот как при этом будет работать маршрутизация - это вопрос, т.к. и Local network и Remote network в Phase 2 на обоих IPsec будут одинаковы  ::)  Проверять надо после создания и поднятия обоих ipsec-каналов сделать след. :
                1. Бегают ли пакеты при одновременно поднятых каналах ибо "вес" у каждого из них одинаков. Будет ли "борьба" за маршрут между ними или "кто первый встал - того и тапки"?
                2. Попеременно один из ваших WAN отключить , проверить работоспособность (одного) канала и что будет происходить при поднятие второго.
                При всех этих операциях обязательно просматривать таблицу маршрутизации на pfsense - что там и как происходит.

                1 Reply Last reply Reply Quote 0
                • A
                  aekvulture last edited by

                  Многотуннельная конфигурация выглядит жутко кривой. Второй туннель будет постоянно и безуспешно пытаться установить соединение, зачем оно надо ? Если упадёт первый порт удалённого роутера то второй туннель соединится со вторым портом удалённого роутера, а мне надо чтоб на первый если он жив, вторичные каналы могут быть лимитными например. К тому же на удалённом роутере второй wan не будет работать пока жив первый ибо у второго метрика большая и через него не пойдёт траффик просто. Тут получается параллельная схема wan1 только в wan1 и соответственно  wan2 только в wan2. А нужна гибкая перекрёстная схема как на циске и решается это только указанием нескольких пиров на отдельно взятом туннеле. Можно конечно создать десяток туннелей перекрывающих все варианты подключения, но это нафиг не нужно. Получается что нормального failover до сих пор так и нет.  На текущий момент вижу единственную возможность нормального построения ipsec failover только с помощью DynDNS указывая в качестве пира DNS имя. Однако это зависимость от стороннего сервиса.

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

                    К тому же на удалённом роутере второй wan не будет работать пока жив первый ибо у второго метрика большая и через него не пойдёт траффик просто.

                    Открою вам "секрет" - у freebsd нет metric в понимании Linuх или даже (sic!) Windows . Есть т.н. "вес интерфейса"

                    http://forums.freebsd.org/showthread.php?t=33006 :

                    You can add a metric to the route(8) command but as far as I know FreeBSD itself doesn't use it.

                    На текущий момент вижу единственную возможность нормального построения ipsec failover только с помощью DynDNS указывая в качестве пира DNS имя. Однако это зависимость от стороннего сервиса.

                    У меня "эта зависимость" работает на паре десятков разномастных железок с "белой" динамикой уже по 5-6 лет. Причем на разных ДинДНС сервисах. Проблем нет.

                    Можно конечно создать десяток туннелей перекрывающих все варианты подключения, но это нафиг не нужно

                    Попробуйте поставить Linux перед Pfsense только для IPsec (зачем?). Или оставьте свою схему с Цисками только для IPSec (тогда нафига весь сыр-бор был?).

                    Или все же сядьте, возьмите ручку и спокойно-вдумчиво нарисуйте для вашего варианта схему всех возможных соединений по ipsec на 2-ух pfsense.

                    Никто и не обещал, что будет легко.

                    P.s.

                    Второй туннель будет постоянно и безуспешно пытаться установить соединение, зачем оно надо ?

                    Вы это проверили? Коннект будет идти на другой ip-адрес Циски. Проверьте сперва.

                    1 Reply Last reply Reply Quote 0
                    • A
                      aekvulture last edited by

                      А весь сыр-бор был исключительно в научных целях  :D Реально я сейчас ничего строить не буду, я лишь хотел разобрать этот момент для того, чтобы быть в теме, знать что такая возможность есть, более того уже знать как это реализовать. А сейчас-то да, на цисках всё работает волшебно, о переключении каналов тока по мониторингу узнаём, а так то даже не чувствуется. Но надеюсь что они допилят возможность указывать несколько пиров.

                      Спасибо за участие  ;)

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

                        Да не за что. Жаль что не "в живую".

                        P.s. Если такая возможность есть\будет во FreeBSD, то к версии 3.х "допилят"

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post

                        Products

                        • Platform Overview
                        • TNSR
                        • pfSense
                        • Appliances

                        Services

                        • Training
                        • Professional Services

                        Support

                        • Subscription Plans
                        • Contact Support
                        • Product Lifecycle
                        • Documentation

                        News

                        • Media Coverage
                        • Press
                        • Events

                        Resources

                        • Blog
                        • FAQ
                        • Find a Partner
                        • Resource Library
                        • Security Information

                        Company

                        • About Us
                        • Careers
                        • Partners
                        • Contact Us
                        • Legal
                        Our Mission

                        We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                        Subscribe to our Newsletter

                        Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                        © 2021 Rubicon Communications, LLC | Privacy Policy