адрес висит на интерфейсе spf2 ?

да

адрес висит на интерфейсе spf2 ?

connection-state=new зачем ?

тогда странное поведение. а как проверка организована, что не блокируется?

всем привет, подскажите пожалуйста, как правильно закрыть порт 161 UDP извне add action=drop chain=input comment="drop UDP SNMP 161 on ISP2" \ connection-state=new dst-port=161 in-interface=sfp2 protocol=udp sfp2 - порт провайдера 161 UDP все равно открыт

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

какое указано в таймаутах

connection-state=new зачем ?

я и так и без пробовал

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

я через 2-3 дня пробовал, все равно открыт

проверяли с наружи сети ?

всё должно работать таким правилом

я через 2-3 дня пробовал, все равно открыт

тогда вместо интерфейса указать адрес и убрать из конфига коннекшн стейт, сбросить в коннтраке все связанные адреса и снова проверить

тогда вместо интерфейса указать адрес и убрать из конфига коннекшн стейт, сбросить в коннтраке все связанные адреса и снова проверить

извините, это где?

извините, это где?

извините, это где?

ip -> firewall -> connections

попробуйте поднять правила выше всех

удалить соединения и проверить

предполагаю что в первом правиле что то напутанно

тогда вместо интерфейса указать адрес и убрать из конфига коннекшн стейт, сбросить в коннтраке все связанные адреса и снова проверить

так можно? у меня там 4 внешних айпи

ой, надо же в src..

ой, надо же в src..

нет, было верно, именно в dst.

так у него ж стоит in interface sfp2

так у него ж стоит in interface sfp2

было да

вот аналогичное правило и всё работает, на всём моём зоопарке.

смотрите первое правило инпут скорее всего в нём загвоздка

смотрите первое правило инпут скорее всего в нём загвоздка

я перевесил, видимо надо подождать

проверяете с наружи сети ?

да

не изнутри же ?

нет

ну я так на всякий уточнить )

))

либо сделать правило в RAW

покажите ещё экспортом первое правило то, которое accept input established, related

покажите ещё экспортом первое правило то, которое accept input established, related

add action=accept chain=forward comment="accept established & related" \ connection-nat-state="" connection-state=established,related,untracked

ну тогда более чем странно

а нету случаем прокидывания портов внутрь ?

в нате

если указать адрес, вот так получается c:\PortQryV2>portqry -n 80.252.144.226 -e 161 -p UDP Querying target system called: 80.252.144.226 Attempting to resolve IP address to a name... Failed to resolve IP address to name querying... UDP port 161 (snmp service): LISTENING or FILTERED community name for query: public Sending SNMP query to UDP port 161... UDP port 161 (snmp service): FILTERED

FILTERED

в нате

оно же туда дойти не должно, вроде?

add action=accept chain=forward comment="accept established & related" \ connection-nat-state="" connection-state=established,related,untracked

мне тут не очень нравится connection-nat-state=""

ну если у него стоит проброс портов, то правило не сработает, потому как это уже форвард а не инпут цепочка\

а если на порт, то: c:\PortQryV2>portqry -n 80.252.144.226 -e 161 -p UDP Querying target system called: 80.252.144.226 Attempting to resolve IP address to a name... Failed to resolve IP address to name querying... UDP port 161 (snmp service): LISTENING or FILTERED community name for query: public Sending SNMP query to UDP port 161... UDP port 161 is LISTENING LISTENING...

мне тут не очень нравится connection-nat-state=""

я переместил правило на 1 строчку

мне тут не очень нравится connection-nat-state=""

add action=accept chain=forward comment="accept established & related" \ connection-nat-state="" connection-state=established,related,untracked

это вообще цепочка forward, а не input

извините, не то вам скинул

add action=accept chain=input comment="accept established & related" \ connection-nat-state="" connection-state=established,related,untracked

первое правило было инпут, второе - форвард

add action=accept chain=input comment="accept established & related" \ connection-nat-state="" connection-state=established,related,untracked

https://help.mikrotik.com/docs/spaces/ROS/pages/328513/Building+Advanced+Firewall в доке как бы нет connection-nat-state="" на что она повлияет...

https://help.mikrotik.com/docs/spaces/ROS/pages/328513/Building+Advanced+Firewall в доке как бы нет connection-nat-state="" на что она повлияет...

да и вроде я не выбирал, как ее убрать...

да и вроде я не выбирал, как ее убрать...

это опять не то правило :) это invalid

вроде так ?

блин сорри

куча правил, запутался..

add action=accept chain=input comment="accept established & related" \ connection-state=established,related,untracked add action=accept chain=forward comment="accept established & related" \ connection-state=established,related,untracked

вроде так, ща попробую на порт настроить

не, то же самое

тогда оставлю на адрес, спасибо за помощь!

тогда оставлю на адрес, спасибо за помощь!

А что надо-то? Открыть всё, запретить UDP 161 ? 😁

А что надо-то? Открыть всё, запретить UDP 161 ? 😁

неее, запретить 161 UDP и все)

ну и tcp, хотя он и так был закрыт

вот аналогичное правило и всё работает, на всём моём зоопарке.

В правильно настроенном файрволле подобные правила с запретами из внешки не нужны. 😁

Всем привет, подскажите можно ли указывать одинаковые сиды для вайфая 2.4 и 5ггц? Спасибо.

неее, запретить 161 UDP и все)

Ну а всё остальное, значит, открыть )

Всем привет, подскажите можно ли указывать одинаковые сиды для вайфая 2.4 и 5ггц? Спасибо.

Можно. Но некоторые клиенты могут начать прыгать туда-сюда.

Еще вопрос, настроил бридж фильтр на hex S все норм работает кроме sfp порта, все что за ним перестает работать. Напомню что sfp порт идет через проц, может в связи с этим бридж фильтер не распростроняеться на этот порт

Можно. Но некоторые клиенты могут начать прыгать туда-сюда.

То есть лучше тогда разные сид?

То есть лучше тогда разные сид?

Лучше попробовать, настроить.. если чудаковатых клиентов не будет - так и оставить. Хотя в некоторых кейсах есть смысл в разных SSID

Можно. Но некоторые клиенты могут начать прыгать туда-сюда.

Представим что клиент подключился к сиду wifi_2g и к wifi_5g то клиент так же будет бегать то туда то сюда таже каша получиться что и с однис сид? или с одним сид это что то другое?

Еще вопрос, настроил бридж фильтр на hex S все норм работает кроме sfp порта, все что за ним перестает работать. Напомню что sfp порт идет через проц, может в связи с этим бридж фильтер не распростроняеться на этот порт

если sfp1 запихали в единый бридж, то фильтеринг на нем работает программно (а скорее всего на всех портах он у вас такой - смотрите, есть ли флаг H напротив портов).

Представим что клиент подключился к сиду wifi_2g и к wifi_5g то клиент так же будет бегать то туда то сюда таже каша получиться что и с однис сид? или с одним сид это что то другое?

В принципе вы правы, если клиент прыгучий, разные SSID его не остановят. Делайте единый.

если sfp1 запихали в единый бридж, то фильтеринг на нем работает программно (а скорее всего на всех портах он у вас такой - смотрите, есть ли флаг H напротив портов).

sfp в одном бридже и флага нет так как на этой модельке sfp на проце но факт в том что в sfp перестает лететь все после включения бридж фильтр

Если SFP порт должен быть нетегированным, то во VLAN Table его и поставьте как нетегированный, а в PVID поставьте нужный VLAN, в котором он должен быть

Если SFP порт должен быть нетегированным, то во VLAN Table его и поставьте как нетегированный, а в PVID поставьте нужный VLAN, в котором он должен быть

Там все только в теге

Вообще на руотерах без аппаратной поддержки с этим влан фильтерингом получаем пенальти около 10-15%, так что на слабых роутерах стоит подумать, можно ли решить задачу без влан фильтеринга

Там все только в теге

Повторюсь, если трафик должен быть нетегированный - то в табоице VLAN так и укажите, что sfp1 - untagged

Вообще на руотерах без аппаратной поддержки с этим влан фильтерингом получаем пенальти около 10-15%, так что на слабых роутерах стоит подумать, можно ли решить задачу без влан фильтеринга

Hex S это не слабый

Всем привет, подскажите можно ли указывать одинаковые сиды для вайфая 2.4 и 5ггц? Спасибо.

Если так ставить вопрос, то даже нужно. Best practice. Учитывая, что у пятерки приоритет.

Повторюсь, если трафик должен быть нетегированный - то в табоице VLAN так и укажите, что sfp1 - untagged

Повторюсь там все в теге за sfp микрот с вланом на порту который смотрит на этот sfp