Взаимодействие peer isolation и protected security level c правилами firewall

[SecretSanta]

Появилась необходимость изолировать WiFi-клиентов друг от друга и запретить доступ к WEB-интерфейсу роутера. Я врубил peer-isolation и protected security level в CLI. Все работает: клиенты перестали пинговаться, WEB-интерфейс не видят. Теперь, допустим, мне надо:

1. Теперь мне надо разрешить доступ к WEB-интерфейсу с одного IP. Я добавил правило в файерволл и теперь я получаю в качестве ответа 403 Forbidden (вместо таймаута - это без добавленного правила). Отсюда первый вопрос: protected security level помимо запрета на уровне файерволла еще и добавляет запрет на уровне веб-сервера или я что-то неправильно делаю?

Правило: Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80.

2. При включенной изоляции, допустим, я хочу разрешить взаимодействие между двумя IP-адресами. Для проверки добавил правила, разрешающие пинговать друг дружку, но не работает. Отсюда второй вопрос: peer-isolation или правила файерволла приоритетнее? Я читал, что у файерволла.

Правило 1: Source IP - 192.168.1.2, Destination IP - 192.168.1.3, Protocol - ICMP,
Правило 2: Source IP - 192.168.1.3, Destination IP - 192.168.1.2, Protocol - ICMP.

P.S. Правила делал через WEB-интерфейс, не CLI. Есть ли разница?

[Werld]

В 29.12.2020 в 21:19, SecretSanta сказал:

Отсюда первый вопрос: protected security level помимо запрета на уровне файерволла еще и добавляет запрет на уровне веб-сервера

Видимо так и есть. Как один из вариантов решения :возвращать на сегмент security-level private, А затем уже в правилах фаерволла для этого сегмента указать разрешающее Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80. И следом запрещающее Source IP - 192.168.1.0/24, Destination IP - 192.168.1.1, Destination port - 80. Если кроме веб-морды надо запрещать доступ к другим службам роутера, также создавать правила запрета на порт 23 (telnet), 22 (ssh) и т.д.

В 29.12.2020 в 21:19, SecretSanta сказал:

При включенной изоляции, допустим, я хочу разрешить взаимодействие между двумя IP-адресами. Для проверки добавил правила, разрешающие пинговать друг дружку, но не работает. Отсюда второй вопрос: peer-isolation или правила файерволла приоритетнее?

Из описания опции peer-isolation "Блокирует передачу трафика от беспроводных клиентов внутри L2-сети." Фаерволл работает на L3, поэтому и не отрабатывают эти правила. Можно сказать, что peer-isolation приорететнее.

В 29.12.2020 в 21:19, SecretSanta сказал:

P.S. Правила делал через WEB-интерфейс, не CLI. Есть ли разница?

Через веб-конфигуратор создаются правила только к входящему трафику интерфейсов.
Через CLI можно создавать правила и навешивать их на любое направление.

Edited December 30, 2020 by werldmgn

[KorDen]

peer-isolation - это именно фильтр общения между клиентами одной точки доступа WiFi

Для проводных хостов в одном L2 сегменте обычно такое называется traffic segmentation но в кинетике его нет. Поэтому на общение между двумя проводными хостами в одном L3-сегменте никак не повлиять, так как для роутера это L2-трафик.

Касательно In/Out.

Исходящие соединения с роутера разрешены по-умолчанию. И даже если запрещены, обычно есть правило типа "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" которое как раз подразумевает неблокирование уже открытых соединений.

[Werld]

16 часов назад, SecretSanta сказал:

Хорошо, допустим, я хочу изолировать всех от всех в локалке (хосты друг от друга, хосты от роутера, роутер от хостов... ну вы поняли) за одним исключением - один хост с ip 192.168.1.2 должен иметь доступ к web-морде на роутере с ip 192.168.1.1. Пишу следующие правила:

1. In:

permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny ip 192.168.1.0/24 192.168.1.1/32

2. Out:

deny ip 192.168.1.0/24 192.168.1.0/24

И я не могу зайти в web-интерфейс с 192.168.1.2. Более того, как только я привязываю второе правило (acl) к интерфейсу, тут же теряется telnet-соединение. То есть либо я что-то делаю неправильно (чего я не исключаю), либо никакого правила вида "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" нет, либо это правило перезаписывается правилом из списка out.

Для запрета доступа к админке роутера всем, кроме 192.168.1.2 достаточно двух правил на in для интерфейса home. 
permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny tcp 192.168.1.0/24 192.168.1.1/32 port eq 80
На out никаких правил при этом не нужно. Правилом  deny ip 192.168.1.0/24 192.168.1.1/32 вы зарежете не только вообще весь доступ к роутеру, включая телнет и проч, но еще и форвард для устройств заодно. Такое правило использовать не надо.

Далее, запретить проводным устройствам общаться между собой правилами фаерволла не получится, т.к.между проводными устройствами ходят кадры через l2-свитч. Запретить беспроводным клиентам общение между собой и проводным сегментом при этом возможно, с помощью peer-isolation.

Edited January 4, 2021 by werldmgn

[Werld]

В 31.12.2020 в 19:51, SecretSanta сказал:

Что если на 192.168.1.2 поднят web-сервер, и я делаю запрос к нему с 192.168.1.3? По логике в моей бошке это должно подподать под In и Out (так как пакеты идут до роутера, а потом от него). Например, я пытался заблочить в качестве эксперимента такой путь только в In правилах, и это не сработало. Значит ли это,  что в таких случаях (когда пакеты идут через роутер, а не инициированы им или он является пунктом назначение - как в п. 1 и п. 2) мы выбираем направление (In или Out) по конечному узлу (то бишь это будет Out, так как последнее направление - от роутера к 192.168.1.2)? Или мы пишем правила и в In, и в Out?

Во-первых, соединение между проводными хостами одного l2-сегмента, как уже написано выше, не заблочить правилами фаерволла на роутере. Поэтому у вас не получилось в качестве эксперимента "заблочить в качестве эксперимента такой путь только в In правилах". Во-вторых, если пакеты все же идут через роутер транзитом не в пределах одной l2, а между сетями (например, когда у вас два сегмента 192.168.1.0/24 и 192.168.2.0/24, или между локальной и глобальной сетью), то запрещающее правило в фаерволле роутера достаточно на in (если запретить инициацию соединения, то никакого ответа и не последует).

Edited January 4, 2021 by werldmgn

[Werld]

1 час назад, SecretSanta сказал:

Мне не нужно запрещать ТОЛЬКО доступ к интерфейсу, а нужно изолировать всех клиентов друг от друга и от роутера (кроме от 192.168.1.2 к web-интерфейсу). Именно поэтому я пишу это правило в Out. Использовать peer-isolation я не могу, потому что эта опция приоритетнее любого разрешающего правила файерволла (как подсказали выше). Скорее всего, мне понадобится позже между отдельными хостами в локалке разрешить траффик на отдельных портах.

Изолировать друг от друга хосты одного l2-сегмента хоть проводные хоть беспроводные (без peer-isolation) не получится никак, не зависимо от того делаете вы правила на in, out или даже nearby)). 
Доступ к самому роутеру при этом запретить можно, в том числе выборочно. Использовать для этого правила на out для интерфейса home концептуально не принято. Но если только так вам удалось добиться желаемой фильтрации доступа к роутеру, то и ладно)

1 час назад, SecretSanta сказал:

Суть моего предыдущего комментария была в том, что написанное в доках и в комменте KorDen (второй абзац) не соответствует дейсвительности (или я неправильно интерпретирую, что имеется в виду) - если разрешить входящий траффик (первое правило In), то исходящий в рамках установленного соединения должен идти нормально и не подпадать уже под правила файерволла (под правило Out), но это не так. Об этом говорит то, что я не могу зайти в интерфейс и что происходит мгновенный разрыв telnet-соединения после привязки правила из Out к интерфейсу (хотя это установленная tcp-сессия).

Вы интерпретируете неправильно. "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" означает, что если имеет место некий, каким каким-то образом разрешенный, исходящий траффик, то в рамках установленного соединения не требуется отдельно разрешать входящий трафик этого соединения. А вот в цепочке OUTPUT нет правила всегда разрешающего уже установленные соединения.
Поэтому когда вы вдруг создаете запрещающее правило на out, то оно запрещает)). Т.е. происходит следующее, хост отправляет трафик на роутер, роутер его принимает, обрабатывает формирует ответ и отправляет назад, только вот из-за появившегося запрещающего правила ответ не доходит. Поэтому я и написал, что концептуально неверно для данного случая запрещающие правила вешать на out. Запрещать надо in, чтобы роутер зря не принимал и не обрабатывал запросы к себе, ответ на которые все равно не дойдет.

Edited January 4, 2021 by werldmgn

[Werld]

1 час назад, SecretSanta сказал:

Невозможность изоляции внутри L2-сегмента без peer-isolation - это архитектурная фишка самого стека или особенность реализации в Keenetic'ах?

Можно сказать, это особенность аппаратной реализации любого маршрутизатора, не только на Кинетиках. Все описанное далее мое ИМХО, так сказать, как я это вижу) Вот возьмем маршрутизатор, у него есть ЦП и есть чип коммутатора. Отдельный чип коммутатора нужен чтобы локальный трафик проводных клиентов не грузил ЦП. Т.е. локальный трафик проводных клиентов нагружает только аппаратный чип свича, соответственно любая фильтрация этого трафика может осуществляться только силами этого чипа, если он такое умеет. По типу, как в некоторых железных управляемых коммутаторах есть опции навроде Traffic segmentation для l2 трафика. Аналогично с wireless чипом. Трафик беспроводных клиентов обрабатывается этим wifi чипом. В отличие от чипа свича, используемый в Кинетике wifi чип имеет функцию изоляции клиентов, что и выведено в настройку peer-isolation. А вот трафик между сетями (например между локальной и глобальной) задействует уже обработку процессором, а значит может быть обработан пакетным фильтром в ядре ОС роутера.  

[SecretSanta]

Quote

Из описания опции peer-isolation "Блокирует передачу трафика от беспроводных клиентов внутри L2-сети." Фаерволл работает на L3, поэтому и не отрабатывают эти правила. Можно сказать, что peer-isolation приорететнее.

Да, это в инструкции к CLI написано. Проглядел в первый раз.

У меня тогда еще вопрос вдогонку по работе файерволла:

1. Допустим я делаю DNS-запрос на роутер - это подподает под направление In;

2. DNS-ответ от роутера подподает под направление Out;

3. Что если на 192.168.1.2 поднят web-сервер, и я делаю запрос к нему с 192.168.1.3? По логике в моей бошке это должно подподать под In и Out (так как пакеты идут до роутера, а потом от него). Например, я пытался заблочить в качестве эксперимента такой путь только в In правилах, и это не сработало. Значит ли это,  что в таких случаях (когда пакеты идут через роутер, а не инициированы им или он является пунктом назначение - как в п. 1 и п. 2) мы выбираем направление (In или Out) по конечному узлу (то бишь это будет Out, так как последнее направление - от роутера к 192.168.1.2)? Или мы пишем правила и в In, и в Out?

[r13]

22 минуты назад, SecretSanta сказал:

Да, это в инструкции к CLI написано. Проглядел в первый раз.

У меня тогда еще вопрос вдогонку по работе файерволла:

1. Допустим я делаю DNS-запрос на роутер - это подподает под направление In;

2. DNS-ответ от роутера подподает под направление Out;

3. Что если на 192.168.1.2 поднят web-сервер, и я делаю запрос к нему с 192.168.1.3? По логике в моей бошке это должно подподать под In и Out (так как пакеты идут до роутера, а потом от него). Например, я пытался заблочить в качестве эксперимента такой путь только в In правилах, и это не сработало. Значит ли это,  что в таких случаях (когда пакеты идут через роутер, а не инициированы им или он является пунктом назначение - как в п. 1 и п. 2) мы выбираем направление (In или Out) по конечному узлу (то бишь это будет Out, так как последнее направление - от роутера к 192.168.1.2)? Или мы пишем правила и в In, и в Out?

Важен первый пакет, далее firewall ведет таблицу активных соединений (contrack) и пропускает пакеты в рамках соединения, а не обрабатывая каждый пакет по отдельности

Edited December 31, 2020 by r13

[SecretSanta]

11 minutes ago, r13 said:

Важен первый пакет, далее firewall ведет таблицу активных соединений (contrack) и пропускает пакеты в рамках соединения, а не обрабатывая каждый пакет по отдельности

1. Это понятно, я не об этом спрашивал. Давайте переформулирую: какова логика в выборе направления (In, Out или оба?), для которого пишутся правила для файерволла, если роутер не является ни source ip (если  source ip, то Out), ни destination ip (если destination ip, то In)? Например, от одного хоста в локалке к другому (ни один из них не является роутером).

2. Ваш ответ навел меня на другой вопрос: допустим, я (192.168.1.2) хочу открыть web-интерфейс (192.168.1.1:80). Для установления сессии мне достаточно разрешить

Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80 (In)?

Или надо еще разрешить

Source IP - 192.168.1.1, Source port - 80, Destination IP - 192.168.1.2 (Out)?

Или вы это и имели в виду (что достаточно первого (In) правила)?

P.S. Извините за, возможно, тупые вопросы.

[r13]

1 час назад, SecretSanta сказал:

1. Это понятно, я не об этом спрашивал. Давайте переформулирую: какова логика в выборе направления (In, Out или оба?), для которого пишутся правила для файерволла, если роутер не является ни source ip (если  source ip, то Out), ни destination ip (если destination ip, то In)? Например, от одного хоста в локалке к другому (ни один из них не является роутером).

2. Ваш ответ навел меня на другой вопрос: допустим, я (192.168.1.2) хочу открыть web-интерфейс (192.168.1.1:80). Для установления сессии мне достаточно разрешить

Source IP - 192.168.1.2, Destination IP - 192.168.1.1, Destination port - 80 (In)?

Или надо еще разрешить

Source IP - 192.168.1.1, Source port - 80, Destination IP - 192.168.1.2 (Out)?

Или вы это и имели в виду (что достаточно первого (In) правила)?

P.S. Извините за, возможно, тупые вопросы.

Логика описана тут

https://help.keenetic.com/hc/ru/articles/360001429839-Как-реализован-межсетевой-экран-

[SecretSanta]

On 12/31/2020 at 5:16 PM, KorDen said:

Исходящие соединения с роутера разрешены по-умолчанию. И даже если запрещены, обычно есть правило типа "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" которое как раз подразумевает неблокирование уже открытых соединений.

Хорошо, допустим, я хочу изолировать всех от всех в локалке (хосты друг от друга, хосты от роутера, роутер от хостов... ну вы поняли) за одним исключением - один хост с ip 192.168.1.2 должен иметь доступ к web-морде на роутере с ip 192.168.1.1. Пишу следующие правила:

1. In:

permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny ip 192.168.1.0/24 192.168.1.1/32

2. Out:

deny ip 192.168.1.0/24 192.168.1.0/24

И я не могу зайти в web-интерфейс с 192.168.1.2. Более того, как только я привязываю второе правило (acl) к интерфейсу, тут же теряется telnet-соединение. То есть либо я что-то делаю неправильно (чего я не исключаю), либо никакого правила вида "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" нет, либо это правило перезаписывается правилом из списка out.

Edited January 3, 2021 by SecretSanta

[SecretSanta]

У меня все клиенты подключены по Wi-Fi (прошу прощения, если из первого поста это не было понятно). По проводу никто не подключен.

7 hours ago, werldmgn said:

Для запрета доступа к админке роутера всем, кроме 192.168.1.2 достаточно двух правил на in для интерфейса home. 
permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
deny tcp 192.168.1.0/24 192.168.1.1/32 port eq 80
На out никаких правил при этом не нужно. Правилом  deny ip 192.168.1.0/24 192.168.1.1/32 вы зарежете не только вообще весь доступ к роутеру, включая телнет и проч, но еще и форвард для устройств заодно. Такое правило использовать не надо.

Мне не нужно запрещать ТОЛЬКО доступ к интерфейсу, а нужно изолировать всех клиентов друг от друга и от роутера (кроме от 192.168.1.2 к web-интерфейсу). Именно поэтому я пишу это правило в Out. Использовать peer-isolation я не могу, потому что эта опция приоритетнее любого разрешающего правила файерволла (как подсказали выше). Скорее всего, мне понадобится позже между отдельными хостами в локалке разрешить траффик на отдельных портах.

Суть моего предыдущего комментария была в том, что написанное в доках и в комменте KorDen (второй абзац) не соответствует дейсвительности (или я неправильно интерпретирую, что имеется в виду) - если разрешить входящий траффик (первое правило In), то исходящий в рамках установленного соединения должен идти нормально и не подпадать уже под правила файерволла (под правило Out), но это не так. Об этом говорит то, что я не могу зайти в интерфейс и что происходит мгновенный разрыв telnet-соединения после привязки правила из Out к интерфейсу (хотя это установленная tcp-сессия).

Если правила Out выглядят так:

permit tcp 192.168.1.1/32 port eq 80 192.168.1.2/32

deny ip 192.168.1.0/24 192.168.1.0/24

то все ОК.

7 hours ago, werldmgn said:

Во-первых, соединение между проводными хостами одного l2-сегмента, как уже написано выше, не заблочить правилами фаерволла на роутере. Поэтому у вас не получилось в качестве эксперимента "заблочить в качестве эксперимента такой путь только в In правилах". Во-вторых, если пакеты все же идут через роутер транзитом не в пределах одной l2, а между сетями (например, когда у вас два сегмента 192.168.1.0/24 и 192.168.2.0/24, или между локальной и глобальной сетью), то запрещающее правило в фаерволле роутера достаточно на in (если запретить инициацию соединения, то никакого ответа и не последует).

Как я уже сказал выше, все подключено по Wi-Fi. Все происходит в рамках одной подсети 192.168.1.0/24.

Edited January 4, 2021 by SecretSanta

[vasek00]

Не много проясню для понимания

1. В базе знаний конечно смотрели https://help.keenetic.com/hc/ru/articles/360001434079 важна картинка и то что ниже

2. В данном примере

Скрытый текст

Wifi интерфейс WifiMaster0/AccessPoint1 , клиент 192.168.130.15/32 и сам роутер 192.168.130.97/32

Пример на простом правиле

 

(config)> interface WifiMaster0/AccessPoint1
Core::Configurator: Done.
(config-if)> ip access-group BLOCK in
Network::Acl: Input "BLOCK" access list added to "WifiMaster0/AccessPoint1".
(config)> access-list BLOCK
Core::Configurator: Done.
(config-acl)> deny ip 192.168.130.15/32 192.168.130.97/32
Network::Acl: Rule accepted.
(config-acl)>

 

По конф файлу

isolate-private
!
access-list BLOCK
    deny ip 192.168.130.15 255.255.255.255 192.168.130.97 255.255.255.255

!
interface WifiMaster0/AccessPoint1
    security-level private

   ip access-group BLOCK in

 

interface Bridge0
    rename Home
    description "Home Lan"
    inherit GigabitEthernet0/Vlan1
    include AsixEthernet0
    include AccessPoint
    include AccessPoint_5G
    security-level private

!
interface PPPoE0
    description RT
    role inet
    security-level public

Цепочки

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

 3969 1102K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
...

   7   420 _NDM_ACL_IN  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
...

   7   420 _NDM_INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 117 packets, 69963 bytes)
 pkts bytes target     prot opt in     out     source               destination         

...
  117 69963 _NDM_ACL_OUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
  117 69963 _NDM_OUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

...

Chain @BLOCK (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       192.168.130.15       192.168.130.97      

Chain _NDM_ACL_IN (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 @PPPoE0    all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0           
...

   0     0 @Wireguard2  all  --  nwg2   *       0.0.0.0/0            0.0.0.0/0           
    0     0 @BLOCK     all  --  ra1    *       0.0.0.0/0            0.0.0.0/0           

Chain _NDM_ACL_OUT (2 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain _NDM_INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
...

    0     0 _NDM_IP_PUBLIC  all  --  *      *       0.0.0.0/0            .....WAN...
    7   420 _NDM_IP_PRIVATE  all  --  *      *       0.0.0.0/0            192.168.130.97      
    0     0 _NDM_IP_PUBLIC  all  --  *      *       0.0.0.0/0            .....Inet..

...

Chain _NDM_IP_PRIVATE (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    7   420 _NDM_IP_PROTECT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain _NDM_IP_PROTECT (1 references)
 pkts bytes target     prot opt in     out     source               destination         

....

Chain _NDM_IP_PUBLIC (6 references)
 pkts bytes target     prot opt in     out     source               destination         

...

Chain _NDM_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination        

 

[SecretSanta]

50 minutes ago, werldmgn said:

Изолировать друг от друга хосты одного l2-сегмента хоть проводные хоть беспроводные (без peer-isolation) не получится никак, не зависимо от того делаете вы правила на in, out или даже nearby)). 

То есть, если я хочу изолировать всех от всех локалке с возможностью в будущем разрешить отдельный траффик между отдельными хостами, единственный вариант - тех, кто должен быть изолирован несмотря ни на что, пихать в одну подсеть и включать peer-isolation; тех, кто должен иметь возможность обмениваться чем-то, в другую подсеть без peer-isolation (то есть с "полным" доступом к друг другу). Или есть еще какие-то варианты?

Невозможность изоляции внутри L2-сегмента без peer-isolation - это архитектурная фишка самого стека или особенность реализации в Keenetic'ах?

50 minutes ago, werldmgn said:

Вы интерпретируете неправильно. "iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT" означает, что если имеет место некий, каким каким-то образом разрешенный, исходящий траффик, то в рамках установленного соединения не требуется отдельно разрешать входящий трафик этого соединения. А вот в цепочке OUTPUT нет правила всегда разрешающего уже установленные соединения.

Я поперепутал опять направления... Теперь все понятно :)

1 hour ago, werldmgn said:

Поэтому я и написал, что концептуально неверно для данного случая запрещающие правила вешать на out. Запрещать надо in, чтобы роутер зря не принимал и не обрабатывал запросы к себе, ответ на которые все равно не дойдет.

Я добавлял это правило, чтобы изолировать хосты друг от друга и роутер от хостов. Но раз хосты все равно не изолировать (только что проверил, действительно не работает), то в нем смысла нет, конечно. Роутер от хостов, как вы и сказали, можно в In.

 

[SecretSanta]

On 1/4/2021 at 8:10 PM, werldmgn said:

Можно сказать, это особенность аппаратной реализации любого маршрутизатора, не только на Кинетиках. Все описанное далее мое ИМХО, так сказать, как я это вижу) Вот возьмем маршрутизатор, у него есть ЦП и есть чип коммутатора. Отдельный чип коммутатора нужен чтобы локальный трафик проводных клиентов не грузил ЦП. Т.е. локальный трафик проводных клиентов нагружает только аппаратный чип свича, соответственно любая фильтрация этого трафика может осуществляться только силами этого чипа, если он такое умеет. По типу, как в некоторых железных управляемых коммутаторах есть опции навроде Traffic segmentation для l2 трафика. Аналогично с wireless чипом. Трафик беспроводных клиентов обрабатывается этим wifi чипом. В отличие от чипа свича, используемый в Кинетике wifi чип имеет функцию изоляции клиентов, что и выведено в настройку peer-isolation. А вот трафик между сетями (например между локальной и глобальной) задействует уже обработку процессором, а значит может быть обработан пакетным фильтром в ядре ОС роутера.

Крутяк, спасибо за объяснение.

Короче говоря, я остановился на данный момент на включенном peer-isolation и следующих правилах на In направлении:

permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 80
permit tcp 192.168.1.2/32 192.168.1.1/32 port eq 23
permit udp 192.168.1.0/24 192.168.1.1/32 port eq 53
deny ip 192.168.1.0/24 192.168.1.1/32

Напоминаю, что изначальной целью была изоляция хостов в локалке друг от друга и от роутера за исключением одного хоста (192.168.1.2) с сохранением доступа к интернету.

P.S. Всем спасибо за помощь.