2wan ipsec failover
-
Есть 2 площадки. На каждой по 2 провайдера. Между площадками поднят ipsec туннель. Сейчас каждой стороны стоит по cisco 1811 каждая из которых с любого из своих 2-х портов может "дозвониться" до любого из 2-х портов другой циски. Т.е. с каждой стороны может упасть любой из 2-х провайдеров, туннель всё-равно будет жить. Можно ли реализовать такую же схему с помощью 2-х pfSense ?
PS: Находил старые топики по этому вопросу, но там так ни к чему и не пришли. Может с новой версией что-то поменялось.
-
Хммм, как бы вот - 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) указываете эту группу в кач-ве шлюза.
Если получится - отпишите с картинками, пожалуйста. Многим пригодится.
-
Спасибо, с этим разобрался. Однако осталась ещё одна непонятка, в настройках IPSEC можно указать только один Remote gateway, а мне нужно указать 2. В циске я просто вбивал пиры один за одним сколько хочешь и она их перебирала при недоступности. Тут конечно можно выйти из положения с помощью DynDNS и в качестве пира указать DNS имя, но зависеть от стороннего сервиса не хотелось бы.
-
Спасибо, с этим разобрался. Однако осталась ещё одна непонятка, в настройках 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 возможно
-
Так как вы описали не получится. В реальности всё выглядит так: System -> Routing -> Groups -> Тут создаём группу из 2-х Gateway -> GWGroup1 (пока был один WAN группа не создавалась). Тут же в настройках группы указываем как должны себя вести шлюзы внутри группы - выставить вес каждого из них или сделать балансировку, как определять падение шлюза в группе и т.д. Потом я создаю одно IPSec соединение и в поле Interface указываю не WAN, а GWGroup1. Вроде бы всё прикольно, но блин, надо вбить 2 хоста в Remote gateway, чтобы туннель мог постучаться на другой интерфейс удалённого роутера при падении первого интерфейса.
-
Т.е. это описанный мною вариант 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 - что там и как происходит.
-
Многотуннельная конфигурация выглядит жутко кривой. Второй туннель будет постоянно и безуспешно пытаться установить соединение, зачем оно надо ? Если упадёт первый порт удалённого роутера то второй туннель соединится со вторым портом удалённого роутера, а мне надо чтоб на первый если он жив, вторичные каналы могут быть лимитными например. К тому же на удалённом роутере второй wan не будет работать пока жив первый ибо у второго метрика большая и через него не пойдёт траффик просто. Тут получается параллельная схема wan1 только в wan1 и соответственно wan2 только в wan2. А нужна гибкая перекрёстная схема как на циске и решается это только указанием нескольких пиров на отдельно взятом туннеле. Можно конечно создать десяток туннелей перекрывающих все варианты подключения, но это нафиг не нужно. Получается что нормального failover до сих пор так и нет. На текущий момент вижу единственную возможность нормального построения ipsec failover только с помощью DynDNS указывая в качестве пира DNS имя. Однако это зависимость от стороннего сервиса.
-
К тому же на удалённом роутере второй 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-адрес Циски. Проверьте сперва.
-
А весь сыр-бор был исключительно в научных целях :D Реально я сейчас ничего строить не буду, я лишь хотел разобрать этот момент для того, чтобы быть в теме, знать что такая возможность есть, более того уже знать как это реализовать. А сейчас-то да, на цисках всё работает волшебно, о переключении каналов тока по мониторингу узнаём, а так то даже не чувствуется. Но надеюсь что они допилят возможность указывать несколько пиров.
Спасибо за участие ;)
-
Да не за что. Жаль что не "в живую".
P.s. Если такая возможность есть\будет во FreeBSD, то к версии 3.х "допилят"
