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

pigbrother

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

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

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

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

GSerg

@pigbrother:

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

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

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

pigbrother

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

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

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

GSerg

@pigbrother:

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

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

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

Scodezan

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


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, конечно немного сложнее…

pigbrother

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

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

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

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.

pigbrother

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

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

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

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

werter

@pigbrother:

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

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

GSerg

@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 .Даже когда будет работать основной интерфейс. Это не совсем то,что нужно.

GSerg

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

Scodezan

@GSerg:

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

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

@GSerg:

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

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

@GSerg:

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

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

@GSerg:

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

DO IT)))

Scodezan

@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)

GSerg

@Scodezan:

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

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

GSerg

@Scodezan:

@GSerg:

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

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

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

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

GSerg

@Scodezan:

@GSerg:

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

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

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

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

Scodezan

@GSerg:

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

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

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

@GSerg:

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

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

GSerg

@Scodezan:

@GSerg:

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

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

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

Scodezan

@GSerg:

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

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

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

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

GSerg

@Scodezan:

@GSerg:

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

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

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

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

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