Doh server connection error idle timeout waiting data

Mikrotik doh server connection error idle timeout waiting data

Wed Jun 10, 2020 1:15 pm

Re: DoH server connection error, idle time out connecting

Wed Jun 10, 2020 2:28 pm

Probaly problem with your connection, but likely these short time errors you will not notice for normal use.

You can also do DoH verification:

Re: DoH server connection error, idle time out connecting

Wed Jun 10, 2020 9:17 pm

Re: DoH server connection error, idle time out connecting

Wed Jun 10, 2020 9:29 pm

Re: DoH server connection error, idle time out connecting

Wed Jun 10, 2020 11:55 pm

how about this error

dns,error DoH server connection error: remote disconnected while in HTTP exchange

Re: DoH server connection error, idle time out connecting

Wed Jun 10, 2020 11:57 pm

Re: DoH server connection error, idle time out connecting

Fri Nov 13, 2020 10:43 pm

After trying to setup DOH on 6.47 (stable) and testing firlware on hex, using opendns, clouflare and google dns i always experience the same behavior. (settings up proper static DNS for the doh server, then ensuring SSL root cert is added)

Setup works very well for 45 minutes to 1h30 and then no more resolution is done. I can reboot the hex and it works again, but after 45 min to 1h30 again it don’t work again.

Log show server time out, while I can access it via IP adress. flushing the DNS cache doesn’t help.

Re: DoH server connection error, idle time out connecting

Mon Dec 14, 2020 11:25 am

Re: DoH server connection error, idle time out connecting

Wed Jan 06, 2021 5:06 am

Re: DoH server connection error, idle time out connecting

Tue Feb 16, 2021 10:23 am

Same issue here. Not any fix yet?

DoH server connection error, idle time out connecting.

Re: DoH server connection error, idle time out connecting

Sat Feb 27, 2021 5:34 pm

Re: DoH server connection error, idle time out connecting

Thu Mar 11, 2021 6:35 pm

I’ve recently tried DoH feature and this error message appears from time to time depending on load.
If you enable logs for dns you can see something like that:

612 Mar/11/2021 18:18:42 memory dns, error DoH server connection error: Idle timeout — connecting
613 Mar/11/2021 18:18:42 memory dns done query: #16331 dns server failure
.
520 Mar/11/2021 18:18:37 memory dns query from 10.10.100.32: #16331 www.google.com. A

Just part of the queries fails. It stay so in any configuration: with google or cloudflare, with or w/o «Verify DoH Certificate», w/ and w/o static records for DoH servers etc.

After removing DoH server error logs disappear.
my fw is 6.48.1

Re: DoH server connection error, idle time out connecting

Mon Jun 21, 2021 7:41 pm

Same issue. HEX S stable 6.48.3, or longterm 6.47.10. Reboot router resolve issue for a time about few hours, maybe less winbox stuck on «Logining. «. Only reboot with power cycle can resolve.
RouterOS developers, please pay attention to this bug (stable and longterm branches). It’s kind of memory leak or something.

In log a lot of:

DoH server connection error: SSL: handshake timed out (6)
DoH server connection error: resolving error

l2tp connections with ipsec stop working and can’t reconnect without reboot with messages in log:
initiator can’t find identity for peer:

Источник

Mikrotik doh server connection error idle timeout waiting data

Маршрутизаторы MikroTik — Обсуждение

Старая программа для конфигурирования — Winbox winbox.exe ( 111.5 КБ )
Новая программа для конфигурирования — Winbox winbox3.exe ( 1.39 МБ )
Версия 3.18 (исправлена совместимость с прошивками 6.43): winbox318.exe ( 1.58 МБ )
Версия 3.19 (исправлен логин в 6.45): winbox.exe ( 1.59 МБ )

]*ssdp:(alive|byebye)|^m-search[9-D ]\*[9-D ]http/1\.1[9-D —

]*user-agent: gnucleus [9-D —

]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [9-D —

Если вам требуется помощь в решении проблемы- выкладывайте свой конфиг: /export hide-sensitive terse

Сообщение отредактировал ferhad.necef — 03.01.23, 15:46

Smartecs, через L7 руки не дошли пока у самого на своём, но вроде как читал через webproxy можно, и вроде как: (где-то вычитал, почему-то запомнилось):
Cоздать разрешающее правило в котором ничего нет, кроме значения accept в action и просто разместить его перед/после правила, которое разрешает доступ.

У меня такая проблема на одном из встроенных в материнскую плату сетевых контроллеров. Так и не поборол, использую тот, который без проблем поднимает 100Мб.

Сообщение отредактировал Shoore — 03.12.14, 00:47

ToMaTo_0,
А после покупки делали полный сброс устройства, потом устанавливали свежую прошивку?

Добавлено 02.12.2014, 23:26:

Shoore,
Кстати думаю сообщения нужно перенести в тему указанную тобой.

ToMaTo_0,
Подключите роутер к другому ПК/ноуту/роутеру к чему нибудь где есть активный ethernet порт и посмотрите в статусе на сколько поднимется порт.
Интересует будет ли держать порт скорость 100/1000мб/с с другим устройством, не вашим ПК.
Также попробуйте на ПК «жестко» зажать порт на 100мб/с.

Сообщение отредактировал ctich — 03.12.14, 00:20

А можно уточнить расстояние «основного пачкорда» ??
Надеюсь не более 90м., и кабель обжат правильно.

Парни подскажите где туплю.
Необходимо доработать схему:
2 port tagged — vlan 55
3 port untagged — vlan 55
5 port tagged — vlan 55,56,57

Для vlan 56,57 создан bridge0 и с ними проблем нет.
Прописываю теперь 55 vlan.
Создаю vlan 55 указываю на interf 5
Создаю bridge 1
В bridge в port создаю приземляю vlan 55 на bridge 1
В bridge в port создаю eth 2 + bridge 1
В bridge в port создаю eth 5 + bridge 1
При такой схеме работает проблем нет, НО как только добавляю к eth 3 + bridge 1 . буквально через 8-15 пингов, канал ложится, с чем у меня вопрос, что не так ? o.O

ctich,
А третий порт у тебя нигде не больше не участвует?

Тут еще можно почитать

На момент тестирования нет, но время от времени он будет также активен, и поэтому должна быть полносвязность между тремя портами (2,3,5).
Может что то в фаерфолах надо подкрутить, завтра буду дальше мучить :scratch_one-s_head:
У меня в схеме ip адреса к вланам не привязаны (вернее не все), основная задача микротика — принять этот влан через аплинковый порт и просвичить на два других, и все ( на cisco, alcatel, huawei, zyxel, dlink как то проще, разрешил, прописал и забыл, а тут. ) .

update
возможно бред, но похоже нужно делать для порта 2+5 = bridge 1, 3+5 bridge 2. (по крайней мере на это натолкнула статья)

Сообщение отредактировал ctich — 03.12.14, 23:57

Источник

Mikrotik doh server connection error idle timeout waiting data

Маршрутизаторы MikroTik — Обсуждение

Старая программа для конфигурирования — Winbox winbox.exe ( 111.5 КБ )
Новая программа для конфигурирования — Winbox winbox3.exe ( 1.39 МБ )
Версия 3.18 (исправлена совместимость с прошивками 6.43): winbox318.exe ( 1.58 МБ )
Версия 3.19 (исправлен логин в 6.45): winbox.exe ( 1.59 МБ )

]*ssdp:(alive|byebye)|^m-search[9-D ]\*[9-D ]http/1\.1[9-D —

]*user-agent: gnucleus [9-D —

]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [9-D —

Если вам требуется помощь в решении проблемы- выкладывайте свой конфиг: /export hide-sensitive terse

Сообщение отредактировал ferhad.necef — 03.01.23, 15:46

Smartecs, через L7 руки не дошли пока у самого на своём, но вроде как читал через webproxy можно, и вроде как: (где-то вычитал, почему-то запомнилось):
Cоздать разрешающее правило в котором ничего нет, кроме значения accept в action и просто разместить его перед/после правила, которое разрешает доступ.

У меня такая проблема на одном из встроенных в материнскую плату сетевых контроллеров. Так и не поборол, использую тот, который без проблем поднимает 100Мб.

Сообщение отредактировал Shoore — 03.12.14, 00:47

ToMaTo_0,
А после покупки делали полный сброс устройства, потом устанавливали свежую прошивку?

Добавлено 02.12.2014, 23:26:

Shoore,
Кстати думаю сообщения нужно перенести в тему указанную тобой.

ToMaTo_0,
Подключите роутер к другому ПК/ноуту/роутеру к чему нибудь где есть активный ethernet порт и посмотрите в статусе на сколько поднимется порт.
Интересует будет ли держать порт скорость 100/1000мб/с с другим устройством, не вашим ПК.
Также попробуйте на ПК «жестко» зажать порт на 100мб/с.

Сообщение отредактировал ctich — 03.12.14, 00:20

А можно уточнить расстояние «основного пачкорда» ??
Надеюсь не более 90м., и кабель обжат правильно.

Парни подскажите где туплю.
Необходимо доработать схему:
2 port tagged — vlan 55
3 port untagged — vlan 55
5 port tagged — vlan 55,56,57

Для vlan 56,57 создан bridge0 и с ними проблем нет.
Прописываю теперь 55 vlan.
Создаю vlan 55 указываю на interf 5
Создаю bridge 1
В bridge в port создаю приземляю vlan 55 на bridge 1
В bridge в port создаю eth 2 + bridge 1
В bridge в port создаю eth 5 + bridge 1
При такой схеме работает проблем нет, НО как только добавляю к eth 3 + bridge 1 . буквально через 8-15 пингов, канал ложится, с чем у меня вопрос, что не так ? o.O

ctich,
А третий порт у тебя нигде не больше не участвует?

Тут еще можно почитать

На момент тестирования нет, но время от времени он будет также активен, и поэтому должна быть полносвязность между тремя портами (2,3,5).
Может что то в фаерфолах надо подкрутить, завтра буду дальше мучить :scratch_one-s_head:
У меня в схеме ip адреса к вланам не привязаны (вернее не все), основная задача микротика — принять этот влан через аплинковый порт и просвичить на два других, и все ( на cisco, alcatel, huawei, zyxel, dlink как то проще, разрешил, прописал и забыл, а тут. ) .

update
возможно бред, но похоже нужно делать для порта 2+5 = bridge 1, 3+5 bridge 2. (по крайней мере на это натолкнула статья)

Сообщение отредактировал ctich — 03.12.14, 23:57

Источник

Mikrotik doh server connection error idle timeout waiting data

Tue Aug 25, 2020 5:23 am

Hello, i don’t know if this should be in Beginner Basics or General but one thing for sure is that i’m new to networking in general so bear with me, (the model i have is hAP ac^2 with default configuration, updated to v6.47.2)

So, i’m trying to get DoH working to avoid ISP from manipulating My DNS requests but even after doing what normis said in here viewtopic.php?t=160243
i keep getting filtered/redirected to ISP’s website full of ads its as if my DNS request have been looked at and modified yet they managed to bypass the DoH Cert verification.. (the website i’m trying to connect is https)

I’ve tried to delete all certification and import the certification again,
I’ve tried to create firewall nat by using something called dstnat in case ISP intercepting port 53 UDP to port other than 53 to OpenDNS port 443 (this is not something i found on mikrotik forum so i’m not sure if this even works),
and i also tried flushing DNS cache both in RouterOS and Windows every time i change something in RouterOS but to no avail..

I’m very confused right now, how can this happen? isn’t the point of DNS-over-HTTPS is to make sure theres no Man-in-the-middle? i tried to look at Torch but i have no idea whats going on there even after i look only the IP that is currently used by My Computer, i need pointers on how to identify the problem with DoH (i don’t know how to check if DoH is actually working)

Источник

Ранее в первой (теоретической) части статьи была подробно описана сущность сетевого соединения глазами ядра маршрутизатора. В текущей части мы закрепим информацию в результате рассмотрения работы прикладного протокола DNS через подсистемы RouterOS.

В заключительной части речь пойдёт о диаграмме потока пакетов, при работе с которой важно понимать сущность рассматриваемого сетевого соединения, а также о не документированной в явном виде особенности работы NAT. Материала достаточно много, и чтобы читатель не потерял смысловую нить к концу статьи, она разделена на 3 части: теория, практика и особенность NAT.

Материалы носят в основном теоретический характер и предназначены для людей, тонко настраивающих Firewall, Qos и маршрутизацию, где им придётся непосредственно работать с рассматриваемыми connections. Цикл статей не предназначен для новичков и может их только запутать. Полагаю, что читатель хорошо знаком с предметом разговора.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Без лишних слов приступим к описанию практической задачи. Имеем классическую локальную сеть, в которой клиенты (в том числе беспроводные) подключены к маршрутизатору (со стороны LAN IP адрес 192.168.1.1, со стороны WAN IP адрес 10.0.2.47) и получают посредством работы DHCP протокола в качестве DNS сервера непосредственно IP адрес роутера. Сам роутер использует в качестве сервера DNS IP адрес Cloudflare (/ip dns set allow-remote-requests=yes servers=1.1.1.1). Пользователь загружает свой ноутбук (PC), подключается к Wi-Fi сети, получает от DHCP сервера IP адрес 192.168.1.2 и в браузере открывает сайт, например, mail.ru. Для простоты сосредоточимся на работе не шифрованного DNS протокола, позволяющего увидеть содержание пакетов на прикладном уровне.

Сколько типов DNS соединений будет создано в RouterOS?

Разберёмся детально и разложим всё по полочкам. Если кто-то не уверен в ответе, то после прочтения ясность будет внесена. В действительности имеем следующие DNS запросы и ответы, передающиеся по транспортному протоколу UDP:

• PC -> MikroTik;
• MikroTik -> DNS servers;
• DNS servers -> MikroTik;
• MikroTik -> PC.

Рассчитываю, что читатель понимает, почему это так, и не отвлекаюсь на описание работы непосредственно DNS протокола. Выделим пакеты каждого варианта запросов, для этого воспользуемся маркировкой трафика:

/ip firewall mangle
add action=mark-connection chain=prerouting comment=
    "DNS catcher PC->MikroTik Connections" dst-address=192.168.1.1 dst-port=
    53 new-connection-mark="DNS catcher PC->MikroTik Connections" 
    passthrough=yes protocol=udp
add action=mark-packet chain=prerouting comment=
    "DNS catcher PC->MikroTik Packets" connection-mark=
    "DNS catcher PC->MikroTik Connections" new-packet-mark=
    "DNS catcher PC->MikroTik packets" passthrough=no
add action=mark-connection chain=prerouting comment=
    "DNS catcher DNS Servers->MikroTik Connections" new-connection-mark=
    "DNS catcher DNS Servers->MikroTik Connections" passthrough=yes protocol=
    udp src-address-list="DNS servers" src-port=53
add action=mark-packet chain=prerouting comment=
    "DNS catcher DNS Servers->MikroTik Packets" connection-mark=
    "DNS catcher DNS Servers->MikroTik Connections" new-packet-mark=
    "DNS catcher DNS Servers->MikroTik Packets" passthrough=no
add action=mark-connection chain=output comment=
    "DNS catcher MikroTik->PC Connections" new-connection-mark=
    "DNS catcher MikroTik->PC Connections" passthrough=yes protocol=udp 
    src-address=192.168.1.1 src-port=53
add action=mark-packet chain=output comment=
    "DNS catcher MikroTik->PC Packets" connection-mark=
    "DNS catcher MikroTik->PC Connections" new-packet-mark=
    "DNS catcher MikroTik->PC Packets" passthrough=no
add action=mark-connection chain=output comment=
    "DNS catcher MikroTik->DNS Servers Connections" dst-address-list=
    "DNS servers" dst-port=53 new-connection-mark=
    "DNS catcher MikroTik->DNS Servers Connections" passthrough=yes protocol= udp
add action=mark-packet chain=output comment=
    "DNS catcher MikroTik->DNS Servers Packets" connection-mark=
    "DNS catcher MikroTik->DNS Servers Connections" new-packet-mark=
    "DNS catcher MikroTik->DNS Servers Packets" passthrough=no

Маркировка осуществляется по схеме: сначала обозначаются соединения (mark-connection) затем пакеты этих соединений (mark-packet). Соединения «PC -> MikroTik» отлавливаются по IP адресу роутера и 53 номеру порта назначения. Здесь и далее я опускаю одинаковый и потому не информативный в текущем контексте префикс «DNS catcher». Соединения «MikroTik -> DNS servers» помечаются только по 53 номеру порта назначения. Соединения «DNS servers -> MikroTik» маркируются по такой же схеме, только в правиле используется 53 порт отправителя. Соединения «MikroTik -> PC» отлавливаются на основе IP адреса маршрутизатора и 53 порта отправителя. Для исключения ошибки перемаркировка пакетов ограничена (passthrough=no). Обращаю внимание, пакетов, а не соединений. Чтобы убедиться в корректности работы Mangle, по очереди зеркалируем пакеты каждого типа соединений. Пример, как это делается для пакетов «MikroTik -> DNS servers», представлен ниже:

/ip firewall mangle
add action=sniff-tzsp chain=postrouting comment="Sniffer"
packet-mark="DNS catcher MikroTik->DNS Servers Packets" sniff-target=
    IP_адрес_принимающего_сервера sniff-target-port=37008

Как сохранить трафик на принимающей стороне, рассмотрено здесь. Для зеркалируемых пакетов не забываем снять ограничение, озвученное выше, и выставить passthrough=yes, иначе правило /ip firewall mangle add action=sniff-tzsp будет проигнорировано. Почему для разных типов соединений используются различные цепочки в Firewall (Prerouting, Output, Postrouting) будет рассмотрено ниже. Для тех, кто вообще не в теме, коротко прокомментирую: пакет проходит через различные части сетевой подсистемы Linux, ядро применяет правила из определённых цепочек (chains) к пакетам. После получения нового пакета от физического уровня ядро активизирует правила в цепочках, соответствующих вводу. Все эти структуры данных обслуживаются ядром. Такая подсистема в целом и является Firewall-ом, который из пространства пользователя создаёт правила и управляет ими. Иллюстрация, взятая здесь, в очень упрощённом варианте отображает связь между различными цепочками:

В качестве DNS клиента удобно использовать встроенную во многие операционные системы программу nslookup, которой можно указать IP адрес DNS сервера (192.168.1.1) куда будет отправлен запрос:

nslookup mail.ru 192.168.1.1

Посмотрим, что представляет из себя каждый тип выделенных нами пакетов:

• Соединения с меткой «PC->MikroTik Connections» (содержат пакеты «PC->MikroTik packets») передают DNS query;

  

• Соединения с меткой «MikroTik->DNS Servers Connections» (содержат пакеты «MikroTik->DNS Servers Packets») также передают DNS query;

  

• Соединения с меткой «DNS Servers->MikroTik Connections» (содержат пакеты «DNS Servers->MikroTik Packets») передают DNS query response;

  
• Соединения с меткой «MikroTik->PC Connections» (содержат пакеты «MikroTik->PC Packets») также передают DNS query response.

  

Видно, что маркировка соответствует своим названиям, и, следовательно, выполнена корректно. Пришло время ответить на вопрос, сколько типов соединений создано в RouterOS? Теоретическая часть цикла статей позволяет нам на него ответить – будет создано 2 типа соединения, которые должны получить метки «PC->MikroTik Connections» и «MikroTik->DNS Servers Connections». Внутри операционной системы созданы всего 2 типа соответствующих сокетов (с одинаковыми Stream index). Хотя с точки зрения UDP протокола, будет 4 типа отправки пакетов, ведь UDP ничего не знает про полезную нагрузку прикладного протокола DNS, и что в нём идут запросы и ответы на них, и какие там существуют клиент-серверные взаимосвязи. Чтобы это проверить, дополним правило для «MikroTik->PC Connections» параметром «established», т.е. соединение, которое установлено ранее:

/ip firewall mangle
add action=mark-connection chain=output comment=
    "DNS catcher MikroTik->PC Connections" connection-state=established 
    new-connection-mark="DNS catcher MikroTik->PC Connections" passthrough=yes 
    protocol=udp src-address= 192.168.1.1 src-port=53

Ничего не изменится, счётчик пакетов будет отрабатывать, потому как соединение было установлено ранее на этапе «PC->MikroTik Connections». А если укажем connection-state=new, то счётчик замрёт, таких новых соединений нет. Попробуем ещё дополнительно повесить указанную марку на соединения, которые ранее не размечались (connection-mark=no-mark):

/ip firewall mangle
add action=mark-connection chain=output comment=
    "DNS catcher MikroTik->PC Connections" connection-mark=no-mark 
    new-connection-mark="DNS catcher MikroTik->PC Connections"
    passthrough=yes protocol=udp src-address=192.168.1.1 src-port=53

Счётчики остановятся и возобновят свою работу только, если мы укажем не пустой маркер, а «PC->MikroTik Connections». Для других правил будет аналогичная ситуация. Однако если заглянуть в Connection tracking, то там можно увидеть следующую картину:

Как видно, маркировка как бы перевёрнута, что вначале может даже ошеломить. Чтобы такого с вами не произошло, разберу ситуацию подробно. Если мы укажем для соединений «MikroTik->PC Connections» и «DNS Servers->MikroTik Connections» условие connection-mark=no-mark, то Connection tracking даст ожидаемый результат:

Без него происходит перемаркировка соединений, а с ним уже существующие соединения не получат новую марку. Вышесказанное звучит достаточно запутанно, поэтому передам туже самую мысль, касательно не корректной ситуации в Connection tracking, другими словами. Внутри маршрутизатора возникает следующая ситуация. DNS запрос от PC поступает на DNS сервер, интегрированный в MikroTik. RouterOS внутри себя создаёт первое сетевое соединение «PC->MikroTik Connections». Далее роутер осуществляет DNS запрос к серверу Cloudflare, и создаётся второе соединение «MikroTik->DNS Servers Connections». Далее от сервиса Cloudflare приходит DNS query response, что является продолжением и окончанием второго соединения. После этого роутер выполняет DNS query response в сторону PC, что является продолжением и окончанием первого соединения. Правилами Mangle мы вмешиваемся в вышеописанные действия.

Первая половина первого запроса у нас маркируется как «PC->MikroTik Connections» (корректно), а вторая половина первого запроса маркируется как «MikroTik->PC Connections» (что и должно было вызвать смуту в нашей голове при просмотре Connection tracking, как показано на рисунке с некорректной ситуацией). На деле это одно и то же соединение внутри RouterOS. Однако половина его вышла с одной меткой, а вторая половина с другой, и Connection tracking отрисовал только ту метку, которая пришла к нему последней (в последнем блоке по движению пакетов внутри операционной системы, об этом подробнее будет в третьей части цикла статей). Для соединений «MikroTik->DNS Servers Connections» и «DNS Servers->MikroTik Connections» возникает ровно такая же ситуация. Поэтому выровнять ситуацию нам помог параметр connection-mark=no-mark.

Отмечу, что если в правилах Mangle указать passthrough=no, которое при срабатывании пропустит трафик, минуя оставшиеся правила маркировки (значение по умолчанию для параметра passthrough=yes, поэтому в явном виде оно не указывается), то при отсутствующем параметре connection-mark=no-mark перемаркировка всё равно произойдёт. Ключевую роль опять же играет прохождение соединений и пакетов внутри операционной системы маршрутизатора, о чём мы подробно поговорим в третьей части цикла статей. Параметр passthrough=no попросту не отработает, так как первая половина соединения и вторая половина соединения проходят различными маршрутами внутри роутера.

Резюмирую вышесказанное. При работе описанной классической сети для одного DNS запроса клиента LAN в реальности UDP соединение отрабатывает 4 раза: в направление роутера, затем до DNS сервера Cloudflare и обратно. Однако RouterOS будет воспринимать их только как 2 соединения: от клиента Wi-Fi в направлении маршрутизатора и обратно, а также от роутера до DNS сервера Cloudflare и обратно. В глазах MikroTik, любой одиночный UDP пакет — это новое соединение до тех пор, пока не будет отправлен ответ в обратном направлении. Когда есть ответ, то это уже для него UDP соединение. Разумеется, вышесказанное правило ограничено во времени в соответствии с таймаутами, о которых речь шла в первой части цикла статей.

Ранее говорилось, что защита роутера от DOS атак на L3 уровне может базироваться на правилах обработки сетевых соединений. На практике это будет выглядеть так:

/ip firewall filter
add action=add-src-to-address-list address-list=DOS address-list-timeout=1h chain=input comment="List DOS" connection-limit=100,32 connection-state=new in-interface=WAN
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS

Логика работы приведённых правил следующая: не более 100 новых сетевых соединений с IP адреса с 32 маской, иначе IP адрес идет в бан. Подробнее про возможности можно почитать здесь. В комментариях правильно отметили, что правильнее банить не в таблице Firewall Filter, а в таблице Firewall Raw, почему это так станет очевидно после прочтения третьей части цикла статей:

/ip firewall raw
add action=drop chain=input comment="Drop DOS list" src-address-list=DOS

▍ Заключение

В статье с практической точки зрения рассмотрено, что такое сетевое соединение в ядре Linux. Внутри RouterOS и других, «Linux based» операционных систем, понятие сетевое соединение не идентично клиент-серверному соединению. MikroTik работает с виртуальными сокетами, под которыми следует понимать совокупность пар IP адрес отправителя и номера порта отправителя, а также IP адрес получателя и номера порта получателя, искусственно введённых для обеспечения функционирования устройства. Это особенно важно при настройке Firewall, а следовательно, и связанных с ним Qos и маршрутизации, в некоторых случаях.

Часть 1
Часть 2 (вы тут)
Часть 3