4. Настройка правил firewall на резервном канале

Настройка правил firewall на резервном канале

  • G

    Доброе утро,господа.
    Ситуация : есть физический хост  с pfsense 2.2.2 , установлены 3 сетевых адаптера -WAN , LAN , OPT1.Есть два канала от провайдеров - на WAN - основной,на OPT - резервный.Пока WAN работает-OPT1 не используется. LAN смотрит в локальную сеть.Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.
    Проблема вот в чём: необходимо,чтобы через резервный канал OPT1 из локальной сети был разрешён только VOIP трафик (порты 5060 и т.п.),а весь остальной трафик был запрещён-ума не приложу,как это сделать. Ситуация наверняка не уни кальная,возможно кто-то решал подобные задачи с помощью pfsens'a.Прошу поделиться мыслями по этому поводу.

    0
  • P

    Это нужно только при падении WAN или всегда?
    Если навсегда - создать на LAN 2 правила - одно запрещающее VOIP с явным указанием шлюза WAN, 2-е разрешающее, с явным указанием шлюза OPT.
    Нужные порты можно завести как алиас, этот алиас затем задействовать в правиле(ах).

    Шлюз указывается Advanced features-Gateway.

    В принципе любые правила можно задавать, указывая вместо default конкретный gateway.

    0
  • G

    @pigbrother:

    Это нужно только при падении WAN или всегда?
    Если навсегда - создать на LAN 2 правила - одно запрещающее VOIP с явным указанием шлюза WAN, 2-е разрешающее, с явным указанием шлюза OPT.

    Шлюз указывается Advanced features-Gateway

    Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль

    0
  • P

    Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль

    Так если WAN падает, VOIP и так пойдет через OPT.

    0
  • G

    @pigbrother:

    Это нужно только на период падения WAN.А по поводу явного указания шлюза -это интересная мысль

    Так если WAN падает, VOIP и так пойдет через OPT.

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

    0
  • G

    @pigbrother:

    В принципе любые правила можно задавать, указывая вместо default конкретный gateway.

    Примерно так:

    1.Разрешение всего трафика через WAN 1
    2.Разрешение VOIP через OPT1
    3.Запрет всего через OPT1

    ?

    0
  • P

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

    Еще раз. Создать создать на LAN 1-е правило,  запрещающее VOIP с явным указанием шлюза WAN.
    Создать на  LAN 2-е  правило, запрещающее все, кроме DNS и VOIP  с явным указанием шлюза OPT.

    0
  • G

    @pigbrother:

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

    Еще раз. Создать создать на LAN 1-е правило,  запрещающее VOIP с явным указанием шлюза WAN.
    Создать на  LAN 2-е  правило, запрещающее все, кроме DNS и VOIP  с явным указанием шлюза OPT.

    Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)

    0
  • P

    Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)

    Так на то и правильные указания tier в failover.
    Для гарантии дайте WAN максимальный Weight в System: Gateways: Edit gateway->adwanced, а OPT - минимальный.
    Но незначительный служебный трафик по OPT все равно будет идти, будет ли его считать провайдер - не знаю.
    Если OPT - PPPOE, например, и задержка на поднятие интерфейса не критична, можно включить Dial on demand в настройках OPT.

    0
  • G

    @pigbrother:

    Я понял Вас,спасибо) Есть не очевидный (видимо) момент -до падения основного канала (WAN) никакого трафика вообще не должно идти через OPT1(трафик дорогой)

    Так на то и правильные указания tier в failover.
    Для гарантии дайте WAN максимальный Weight в System: Gateways: Edit gateway->adwanced, а OPT - минимальный.
    Но незначительный служебный трафик по OPT все равно будет идти, будет ли его считать провайдер - не знаю.
    Если OPT - PPPOE, например, и задержка на поднятие интерфейса не критична, можно включить Dial on demand в настройках OPT.

    Большое спасибо за подробные рекомендации ) OPT как раз PPPOE .
    Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

    Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?


    0

  • У Вас сейчас весь трафик идет через WAN_DHCP6.  Далее, sip чаще всего исп. UDP - у Вас же стоит TCP во 2-м правиле сверху.

    0
  • D

    @werter:

    У Вас сейчас весь трафик идет через WAN_DHCP6.

    Т.е. порядок правил не корректен.

    0
  • G

    @werter:

    У Вас сейчас весь трафик идет через WAN_DHCP6.

    Но физически WAN_DHCP6 выключен,и весь трафик идёт через OPT1.
    Поле Gateway вообще за что отвечает и на что влияет?

    0

  • sip чаще всего исп. UDP - у Вас же стоит TCP во 2-м правиле сверху.

    0

  • Но физически WAN_DHCP6 выключен,и весь трафик идёт через OPT1.

    Reset states сделайте.

    Поле Gateway вообще за что отвечает и на что влияет?

    Еще и как. Если только правильно настроено.

    0
  • G

    @dvserg:

    @werter:

    У Вас сейчас весь трафик идет через WAN_DHCP6.

    Т.е. порядок правил не корректен.

    А если поменять порядок правил,и поставить allow VOIP для OPT1 то весь трафик будет идти через OPT1(резервный канал)  всегда  независимо от того,работает ли WAN..
    Задача в том,чтобы тем или иным образом
    а) Заставить ВЕСЬ трафик в штатном режиме(это когда WAN работает) ходить через WAN -и VOIP  в том числе.OPT при этом поднят,но трафик через него должен быть запрещён-даже VOIP (канал этот резервный,трафик на нём тарифицируется довольно дорого)
    б)При переключении на резервный канал OPT через него разрешается только хождение VOIP (SIP ,RTP ну и DNS).
    Возможно ли такое сотворить с помощью Pfsense? Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.

    0
  • P

    Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
    Поставьте  Default allow LAN to any rule последним, а свои правила - выше него.

    WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.

    Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.

    Указание  поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.

    0
  • G

    @pigbrother:

    Ваше Default allow LAN to any rule, разрешающее все всем стоит выше остальных правил, из-за чего они не действуют - до них просто дело не доходит (правила выполняются сверху вниз).
    Поставьте  Default allow LAN to any rule последним, а свои правила - выше него.

    WAN_DHCP6 реально имет адрес IPv4 или IPv6? В правиле ведь явно задано IPv4. Без необходимости IPv6 использовать не надо.

    В реальности 4 версия IP,название просто осталось.Спасибо,сейчас попробую поменять правила местами.

    0
  • P

    Спасибо,сейчас попробую поменять правила местами.

    В принципе правильно расположенное разрешающее правило с dst-портом 5060 с указанием шлюза OPT одновременно запретит такому трафику ходить через шлюз WAN

    Не забывать reset states или reboot.

    0
  • G

    @pigbrother:

    Появилась было надежда с указанием в поле "Gateway" целевого шлюза для правила,но видимо это означает не то,что я думаю.

    Указание  поля Gateway позволяет привязать любое правило к шлюзу. Описанная вами задача выглядит решаемой.

    Увы,это иллюзия и нативными средствами pfsense 2.2.2 эту задачу решить не получится.Загвоздка в том,что правило разрешающее только  VOIP через определённый интерфейс должно работать только при условии , что другой интерфейс лежит . Остаётся только организовать кластер pfsens'ов,или писать скрипты.

    0
  • S

    Не знаю что вы там городите, лично у меня последовательность

    
allow IPv4 TCP 192.168.1.244 * *  Ports80443  GW_MARK  none  (Vahta)
allow IPv4 TCP  LocalNet    * *  Ports80443  prio_mark  none  (MAIN ALLOW)

    запрещает компьютеру 192.168.1.244 переходить на резервный канал. Где GW_MARK основной шлюз, prio_mark - фаловер.

    С VoIP, конечно немного сложнее…

    0
  • P

    только при условии , что другой интерфейс лежит.

    Да, в правилах нет возможности привязки к состоянию шлюза\интерфейса.
    А не поможет ли  Allow default gateway switching?

    https://forum.pfsense.org/index.php?topic=45081.0

    0

  • 1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

    2. block IPv4 UDP  LAN subnet *  **!**5060 (SIP) OPT1  none

    3. allow IPv4 * LAN subnet  * * *  WAN_GW none

    А не поможет ли  Allow default gateway switching?

    Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
    Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.

    0
  • P

    Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен\может блокировать.

    _1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

    2. block IPv4 UDP  LAN subnet *  !5060 (SIP) OPT1  none_

    А эти правила не дублируют друг друга?

    0

  • @pigbrother:

    Так ТС OPT вроде нужен как резервный исключительно для SIP. Все, кроме SIP для OPT он согласен блокировать.

    Верно. Пускай ТС пробует.

    0
  • G

    @werter:

    1. allow IPv4 UDP  LAN subnet *  5060 (SIP) OPT1  none

    2. block IPv4 UDP  LAN subnet *  **!**5060 (SIP) OPT1  none

    3. allow IPv4 * LAN subnet  * * *  WAN_GW none

    А не поможет ли  Allow default gateway switching?

    Возможно прийдется запретить это дело. Иначе он весь трафик пустит через OPT1 в случае падения дефолтного канала.
    Проверяйте, выдернув кабель из WAN и логируя трафик в правилах fw.

    Если я верно понимаю,то первая строчка этого правила направит весь трафик SIP на OPT1 .Даже когда будет работать основной интерфейс. Это не совсем то,что нужно.

    0
  • G

    В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.Тему можно закрывать.

    0
  • S

    @GSerg:

    В общем,природа правил pf просто не даст сделать так,как мне нужно.Можно разрешить только трафик определённого типа по определённому маршруту но всегда.

    Так чтоб по типу надо смотреть в сторону L7, что кстати в 2.2.2 недоступно.
    Доступно по номеру+типу порта, адресу источника запроса и адресу назначения.

    @GSerg:

    Если указанный в правиле маршрут недоступен,перехода к следующему правилу не происходит.

    Верно, поэтому есть резервирование.

    @GSerg:

    Резервирование (failover) настроено через System->Routing->Groups с помощью "Tier", переключение по триггеру "Member down" происходит успешно.

    В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.

    @GSerg:

    Тему можно закрывать.

    DO IT)))

    0
  • S

    @GSerg:

    Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

    Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

    так пробовали?

    ![2015-07-01 14-29-16 ???????? ??????.png](/public/imported_attachments/1/2015-07-01 14-29-16 ???????? ??????.png)
    ![2015-07-01 14-29-16 ???????? ??????.png_thumb](/public/imported_attachments/1/2015-07-01 14-29-16 ???????? ??????.png_thumb)

    0
  • G

    @Scodezan:

    В общем то здесь вопрос, как Вы идентифицируете VoIP трафик. В моём случае открытие порта 5060 не дало ожидаемого результата –- звонок есть, голоса нет. Пришлось разрешать всё для конкретных IP SIP серверов.

    Дело в том,что вкупе с SIP трафиком телефония использует непосредственно для передачи голоса rtp трафик.

    0
  • G

    @Scodezan:

    @GSerg:

    Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

    Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

    так пробовали?

    По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
    всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

    0
  • G

    @Scodezan:

    @GSerg:

    Теперь далее- не работают почему-то вот эти правила (на скриншоте) :

    Трафик продолжает успешно ходить,ничего не дропается.ЧЯДН?

    так пробовали?

    Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.

    0
  • S

    @GSerg:

    По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
    всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

    Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что интерфейс шлюз будет другой. Всё зависит только от Вас.

    А первые два правила защищают от ошибок конфигурирования fw

    @GSerg:

    Ваши правила корректны,так всё работает в рамках функционала pfsense.К сожалению,решение моей задачи за эти рамки слегка выходит.

    ааа??? Ну что ж. Найдёте лучшее решение, добро пожаловать.

    0
  • G

    @Scodezan:

    @GSerg:

    По этим правилам всё что "не телефония" пойдёт через один интерфейс,а
    всё что " телефония" пойдёт через другой.Но это не совсем то,что нужно.

    Телефония, по моим правилам, через фаловер, а это вовсе не говорит о том что интерфейс шлюз будет другой. Всё зависит только от Вас.

    Я интерпретировал Ваш пример применительно к своим условиям.В целом Ваш посыл понятен.
    Вы ведь не упускаете из виду,что моя задача состоит в том,чтобы через резервный OPT1 шёл только трафик voip и только когда лежит основной интерфейс?Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.
    Если у Вас есть решение как сделать это pfsens'ом , сделайте милость,избавьте от необходимости искать лучшее решение. :)

    0
  • S

    @GSerg:

    Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.

    Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.

    Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.

    Кстати, на каких кодеках работаете?

    0
  • G

    @Scodezan:

    @GSerg:

    Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.

    Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.

    Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.

    Кстати, на каких кодеках работаете?

    Телефонией занимаются другие,поэтому не знаю  :)
    Проглядел возможность указания в правилах фаервола группы шлюзов. Это выглядит как возможное решение.Буду пробовать.

    0

  • @GSerg:

    @Scodezan:

    @GSerg:

    Пока основной работает-никакому трафику идти через OPT1 нельзя,даже voip.

    Если закрыть глаза на инертность при возврате основного канала в работу, то всё работает так как надо.

    Для сокращения инерции нужен некий скрипт, который будет рвать PPPoE и, соответственно, текущие разговоры.

    Кстати, на каких кодеках работаете?

    Телефонией занимаются другие,поэтому не знаю  :)
    Проглядел возможность указания в правилах фаервола группы шлюзов. Это выглядит как возможное решение.Буду пробовать.

    Если есть возможность, то настоятельно рекомендую перейти на IAX2. Намного упрощает жизнь. Хотя бы тем , что открывать прийдется всего лишь один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).

    0
  • G

    @werter:

    один UDP-порт и для сигнального трафика и для голоса (вместо кучи udp в случае sip + rtp ).

    Отличная рекомендация,спасибо!

    0
  • P

    Присоединяюсь к благодарности за рекомендацию. Вот только полно железа, которое про IAX2 не слышало и не услышит.
    Как решение представляется некий прокси  IAX2->SIP
    https://groups.google.com/forum/#!topic/taug-archive/SR_VJK9tRko

    0

  • 2 pigbrother

    https://github.com/primuslabs/iaxproxy

    When an IAX2 end point connects to IAXProxy the endpoint information is looked up in Redis and assuming the IAX2 device passes authentication then a SIP Peer and SIP Registrar are created on the users behalf

    Мне кажется или оно для другого предназначено ? Т.е. у меня изначально есть iax2-уст-во и мне его надо подключить к только-sip-АТС ? Так asterisk и так iax2 прекрасно поддерживает.

    P.s. Сейчас даже недорогое железо поддерживает IAX2. Из ip-phone посмотрите в сторону ATCOM 610\620.

    0
Log in to reply
 

Products

Services

Support

News

Resources

Company

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 for past announcements.

© 2020 Rubicon Communications, LLC | Privacy Policy