Почему работает DHCP у Mikrotik?

Question

[70-C9-4E-54-03-2F]

Узнал, что DHCP работает по UDP на порту 67 (у сервера) и 68 (у клиента). Чисто ради практики решил на Mikrotik дропать поступающие в Микротик пакеты на порт 67 UDP и выходящие из Микротик пакеты на порт 68. В итоге получил следующее:

ip firewall filter add chain=input protocol=udp dst-port=67 action=drop
ip firewall filter add chain=output protocol=udp dst-port=68 action=drop

Пробовал эти команды и отдельно, и вместе, но устройства все равно почему-то получают динамически всю информацию: IP, маску, ДНС и шлюз. Почему так?
Буду благодерен!

Comments

[Alexey Dmitriev]

А если вместо задавания вопроса поставить Wireshark, включить сниффинг трафика - сделать ipconfig /release и /ipconfig /renew и посмотреть в дамп трафика?

[70-C9-4E-54-03-2F]

Alexey Dmitriev, Пробую сниффить через встроенный инструмент микротика Packet Sniffer. В комментариях под ответом AUser0 отправил скрины

Answer 1

[Victor]

Всё это происходит внутри бриджа, скорее всего. Значит, надо эти же правила ставить в bridge - filter. Без дополнительных настроек фаервол не действует на бридж.

Comments

[70-C9-4E-54-03-2F]

Спасибо, спали мой мозг! Добавил правило:

interface bridge filter add chain=output mac-protocol=ip ip-protocol=udp dst-port=68
 action=drop

Видно в Packet Sniffer, что роутер отвечает на DHCPDISCOVERY и посылает DHCPOFFER. Но DHCPREQUEST не приходит, а значит DHCPOFFER благополучно дропнулся)
А ноут получил APIPA адрес

Answer 2

[powerlift]

В RouterOS DHCP-пакеты попадают в DHCP-клиент и в DHCP-сервер до попадания в IP Firewall, если речь идёт об IPv4.
Можно очень долго искать на форумах и в документации Mikrotik информацию про эту особенность, но не найти. Но выявляется эта особенность довольно легко на самом простом лабораторном стенде, что я и сделал во времена, когда только начинал администрировать оборудование Mikrotik.

Выбранный вами в качестве решения ответ Victor вводит в заблуждение - Bridge Filter и IP Firewall не связаны между собой. Просто в случае когда DHCP-сервер/клиент находится на Bridge-интерфейсе, то есть DHCP-трафик проходит через Bridge, то появляются два возможных варианта фильтровать DHCP-пакеты в Bridge:
1) использовать Bridge Filter для фильтрации
2) включить прохождение всего трафика Bridge через IP Firewall /interface bridge settings set use-ip-firewall=yes , что позволит фильтровать DHCP-пакеты непосредственно в IP Firewall

В IPv6 ситуация уже обстоит иначе - DHCPv6-пакеты сначала проходят через IPv6 Firewall прежде чем попасть в DHCP-клиент. С DHCP-сервером не проверял, но предполагаю, что аналогично.

Comments

[Владимир Г]

Добрый день! Для ether1 применимо? или делать bridge_wan с мастер-интерфейсом ether1?

Answer 3

[Drno]

а указать интерфейс? и отключить fasstrack ?

Comments

[70-C9-4E-54-03-2F]

Насколько я понимаю, если не указывать интерфейс, то он будет применен ко всем. Насчет fasstrack - не знаю, что это, погуглю

[70-C9-4E-54-03-2F]

Убрал у бриджа Fast Forward, в фаерволе нет fasstrack тоже. Пытался добавить интерфейс, но тоже ничего не вышло

[Valentin Barbolin]

70-C9-4E-54-03-2F, так же очередность правил должна быть, возможно выше этих правил есть разрешающее правило.

[70-C9-4E-54-03-2F]

Valentin Barbolin, у меня в ip firewall filter кроме этих двух нет ничего. Перед тестом сбрасывал микротик в ноль и конфигурировал с нуля. Все что сделал, это создал и настроил бридж, настроил dhcp-server, получил интернет по dhcp-client, сделал nat, сконфигурировал wlan1 и добавил эти два правила

Answer 4

[AUser0]

70-C9-4E-54-03-2F, Загляните в Tools -> Packet Sniffer. Впишите туда "UDP" и 67-ой порт, и смотрите, какие пакеты откуда-куда приходят-уходят. Если правила работают - то будет логирован только приход пакетов на физический интерфейс, но не ответы на них... Поможет найти "мокрый пол".

P.S. Ну и логирование работы DHCP Server, тоже полезно видеть.

P.P.S. DHCP рассылаются броадкастом, может на них отвечает кто-то другой?

Comments

[70-C9-4E-54-03-2F]

Поигрался со снифером и узнал, что несмотря на эти правила, микротик получает dhcp-discovery от устройства и затем, почему-то, отвечает ему. Пробовал даже блокировать все поступающие широковещательные запросы:

ip firewall filter add chain=input dst-address=255.255.255.255 action=drop

Но все равно микротик получает запросы и отвечает на них, выдавая айпи. Даже уже и не знаю, в чем проблема

[AUser0]

70-C9-4E-54-03-2F, проверка:

ip firewall filter add chain=input protocol=icmp action=reject

, и пинговать со своего компьютера.
Если PING идёт - значит правила НЕ работают... искать причину неработы правил.

[70-C9-4E-54-03-2F]

AUser0, Сейчас посмотрел пакеты по всему бриджу, оказывается, что устройства использовали DHCPv6 по портам 546-547. Сейчас попытаюсь это все дело заблокировать. Как получится, отпишусь.
И попинговать тоже попробую на всякий

[70-C9-4E-54-03-2F]

AUser0, Попробовал. Добавил два правила дропающих порты для DHCPv6, как приходящие запросы, так и исходящие из микротика. Устройства все равно как-то умудряются получать адрес. Пробовал блокировать icmp = все работает: "Заданная сеть недоступна"

Из логов видно, что хоть устройство и посылает DHCPv6, но получает адрес от микротика через порт 67-68.
Пакеты с пустым IPv6 - это широковещательные запросы, которые посылает сам микротик по wlan1 интерфейсу

[70-C9-4E-54-03-2F]

Это все правила:

[AUser0]

70-C9-4E-54-03-2F, а вот еще вариант: адрес 192.168.0.1 точно находится на исследуемом Mikrotik-е? Проверяется в /ip address print, ну или "IP" -> "Addresses" в WinBox.

P.S. Хотя да, сразу видно, 192.168.0.1 - это его. Вон, в PacketSniffer-е tx-нутый пакет пролетел, значит с этого Mikrotik-а был отправлен.