MultiWan не работает без Reset States



  • Настроено всё по инструкции http://macrodmin.ru/2012/02/multiwan-v-pfsense-podkljuchenie-k-dvum-provajderam
    WAN1 основной и WAN2 запасной. Tier 1 и Tier 2 соответственно. WAN1 с динамическим адресом, WAN2 со статическим, без всяких туннелей.
    И всё бы хорошо, но вот если оставить пинг до 8.8.8.8 например, и отключить основной канал, на него переключается всё, кроме этого пинга. До тех пор пока не сделаешь Reset States.
    Та же ситуация наблюдается при обратном переключении - восстанавливаю основной канал, но пинг до 8.8.8.8 идёт всё еще по старому, до тех пор, пока не сделаешь Reset States.
    Очевидно, что так не только с пингами, но и со всеми подключениями, висящими постоянно. Хотя все новые соединения происходят по правильным каналам. Что в корне не правильно. Как быть? :(



  • Это пробовали?

    Multi-WAN in pfSense 2.1 works just like Multi-WAN on 2.0.x so the basics are all identical.

    The main difference is that with 2.1 you can setup Multi-WAN for IPv6.

    In the default configuration on pfSense 2.1, "State Killing on Gateway Failure" is not active. Because of this, Multi-WAN may not work ideally out of the box. For example, if you want to force connections to failover from WAN1 to WAN2, you will want to enable the option. It can be found under System > Advanced on the Miscellaneous tab, under Load Balancing.

    И в той же закладке поиграйте с

    Allow default gateway switching



  • Снятие галки State Killing on Gateway Failure помогло! После пропадания основного канала, через три потерянных пакета, пинг возобновляется через резервный канал сам! Спасибо большое!
    Allow default gateway switching я ставил еще в начале, когда всё делал по инструкции из ссылки в первом посте.
    Но столкнулся с новой неприятностью:
    При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как сделать, что бы это работало и в обратную сторону?



  • Снятие галки State Killing on Gateway Failure помогло!

    Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.

    По крайней мере в 2.0.3 failower корректно отрабатывает, настройки State Killing on Gateway Failure в 2.0.3 вообще нет.

    При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?

    Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.

    А как\чем  вы смотрите, с какого шлюза идет пинг?



  • @pigbrother:

    Снятие галки State Killing on Gateway Failure помогло!

    Странно, по идее именно задействование State Killing on Gateway Failure должно было помочь.

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

    @pigbrother:

    А как\чем  вы смотрите, с какого шлюза идет пинг?

    Я делаю трасерт во втором окне параллельно и вижу, что трасерт проходит по старом маршруту.
    После Reset States начитнает работать по правльному.



  • У меня в версии 2.1.4 эта галка была по умолчанию, и именно после её снятия заработало как надо.

    Вероятно авторы pfSense перепутали поведение\описание этой настройки.



  • @pigbrother:

    При переключении обратно, с резервного канала на основной, старый пинг продолжает работать по старому маршруту, пока его не остановишь и не подождешь с пол минуты. Как >сделать, что бы это работало и в обратную сторону?

    Это должно срабатывать при задании Tier 1\Tier 2, похоже при возобновлении работы Tier 1 не происходит сброса states, как это происходит при его падении.

    Так как решить проблему без ручного сброса states? Хотелось бы автоматическую систему =(



  • Бредовая идея, но :
    1. Делаем reset states руками.
    2. Возвращаем "галку" на State Killing on Gateway Failure.
    3. Снова делаем reset states руками.
    4. Проверяем работу failover.

    Почему ? Потому что именно включение этой опции заставляет корректно работать failover.

    P.s. Отпишитесь разработчикам pfsense, если все же проблема не решается. Этим поможете многим (тысячам) :)
    Заранее благодарен.



  • @werter:

    Бредовая идея, но :
    1. Делаем reset states руками.
    2. Возвращаем "галку" на State Killing on Gateway Failure.
    3. Снова делаем reset states руками.
    4. Проверяем работу failover.

    Почему ? Потому что именно включение этой опции заставляет корректно работать failover.

    Попробовал по вашей схеме. Не помогло.
    Затем вчитался в коммент к галочке:
    The monitoring process will flush states for a gateway that goes down if this box is not checked. Check this box to disable this behavior.
    Выходит галочки не должно быть, что бы работало. Ну и ладно, без неё работает переключение хорошо.
    Но проблема при возврате на основной интернет канал остаётся! Reset states не происходит! Новые соединения работают по основному каналу, а старые, продолжают работать по резервному! Как это победить?
    Перешел даже на последнюю версию 2.1.5. Полностью переустановил всё с форматированием. Та же проблема.



  • В 2.1.2 все работает норм. Странно, но галочка state killing
    Стоит по умолчанию. В начале у меня были траблы с переключением при падении, но проблема решилась галкой Allow default gateway switching. По поводу возврата на основной шлюз, я считаю, да так и есть в моей реализации, что переключение обратно должно произойти по закрытию старых сессий, то есть все новые сессии будут открываться на восстановившемся канале.
    Такой способ правильнее для конечного сайта(ресурса).
    И вот еще, 30 сек на самом деле долго для переключения, скорее всего из за dhcp на wan, хоть и наверняка у твоего провайдера твой мак уже сопоставлен с ip. Попробуй сделать default gateway интерфейс со статикой и протестировать схему.



  • Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
    Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
    как сделать?



  • Извини, но я хз.



  • @ton:

    Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
    Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
    как сделать?

    В опциях правил, разрешающих телефонный трафик, есть опция, управляющая поведением этого трафика в States. По умолчанию там Keep state. Может быть поменять его на другую опцию - no-state ?



  • Проблема была в том, что был выключен мониторинг маршрута резервного канала, который должен пинговать шлюз на доступность.
    Всем спасибо за страдания! =)



  • @ton:

    Очень нужно, что бы Reset States происходил при переходе с резервного канала на основной!
    Телефонный шлюз к сожалению постоянно поддерживает соединение открытым, и остаётся на резервной линии постоянно. А я хочу что бы он возвращался в основной канал! =(
    как сделать?

    В телефонном оборудовании (как правило сервер) есть опция, которая постоянно посылает пакеты. Изза того, что state всегда поддерживается - мы видим то, что траффик не уходит в новый маршрут. Я сделал на своём астериске  quality =60000 и всё стало норм.


Locked