http://mikrotik.moscow Новое в теме правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sun, 02 Aug 2026 23:00:27 -0400 правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
На практике это часто случается потому, что люди удивляются — как так, можно пинговать интерфейсы, которые заблокированы правилами фаервола, и получать ответ? Пример: VLANX пингует IP-адрес VLANY и наоборот, и начинается паника… Нет, ничего страшного. Это ожидаемое поведение интерфейсов на устройстве MT. L2-структура VLAN предотвращает передачу реальных данных между VLAN, так что с этой стороны переживать не стоит. К тому же, блокировка трафика с vlanx на vlany с помощью правил «drop all» или явных правил полностью останавливает передачу любых данных между VLAN на уровне L3. Не падает ли небо? Нет. В итоге, происходят забавные вещи, причины которых уже объясняли другие, но какая разница? Главное — данные между VLAN не проходят, а это и есть цель. Всем хорошего «удовлетворённого» дня!
13.07.2022 14:10:00, anav.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421998 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421998 Wed, 13 Jul 2022 14:10:00 -0400 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
Привет! Я наткнулся на вашу беседу, так как у MikroTik в расширенном руководстве по файрволу есть правило для DHCP, и мне было интересно, зачем оно нужно. В итоге я пришёл к выводу, что забыли чётко указать сценарий использования этого туториала.

Читайте эту тему — мне кажется, что варианты использования нужно явно прописать.  

DHCP-сервер находится в том же широковещательном домене.  
Это, как объяснил cdiedrich в посте №2. Единственный способ предотвратить неправильную работу DHCP — это добавить DHCP Snooping и DHCP Option 82. Но не все чипы коммутаторов это поддерживают, иначе придётся обеспечивать прохождение трафика через CPU или работать с ACL.  
Если это программный мост (без аппаратного ускорения портов), можно использовать Bridge Filter, как показано в разделе «Flow of Bridged Packet». Возможно, поможет и этот форум: http://forum.mikrotik.com/t/exact-steps-to-block-rogue-dhcp-servers/20839/13.  

DHCP-сервер не в том же широковещательном домене.  
В таком случае DHCP-запросы покидают домен и маршрутизируются на третьем уровне. IP-Firewall может их заблокировать (и только тогда).
13.07.2022 14:04:00, PackElend.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421997 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421997 Wed, 13 Jul 2022 14:04:00 -0400 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
До версии 6.40.1 фильтрация DHCP-запросов на WAN-порту работала. В более поздних версиях я пытался включить функцию «use-ip-firewall» и добавить ложное правило DHCP.  
/interface bridge settings set use-ip-firewall yes/no  
[admin@Client] > /interface bridge settings print
   use-ip-firewall: yes  
  use-ip-firewall-for-vlan: no  
  use-ip-firewall-for-pppoe: no  
   allow-fast-path: yes  
 bridge-fast-path-active: no  
 bridge-fast-path-packets: 0  
 bridge-fast-path-bytes: 0  
 bridge-fast-forward-packets: 0  
 bridge-fast-forward-bytes: 0  
rougeDHCP: input,udp,src67,dst68,wan,log  

Это работает частично. Но почему Mikrotik изменил такое поведение?  

24.03.2019 06:40:00, onlineuser.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421996 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421996 Sun, 24 Mar 2019 06:40:00 -0400 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
Спасибо, действительно, doc было бы здорово. Ради забавы попытался вставить в таблицу RAW, но «не повезло».
23.01.2019 18:41:00, sebastia.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421995 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421995 Wed, 23 Jan 2019 18:41:00 -0500 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
Есть ещё одна дискуссия по этой теме: http://forum.mikrotik.com/t/impossible-to-block-dhcp-server-by-design-or-bug/32434/1. Я не понимаю почему, но это поведение зафиксировано, подтверждено MT, и есть приемлемое решение — использовать фильтр моста. Возможно, было бы полезно иметь документацию по этому конкретному ограничению.
23.01.2019 09:19:00, nescafe2002.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421994 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421994 Wed, 23 Jan 2019 09:19:00 -0500 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
К сожалению, вы правы. И я говорю «к сожалению», потому что это просто не имеет смысла и противоречит логике, ведь протокол использует UDP поверх IP, который обычно обрабатывается IP-файрволом. Раньше это явно нужно было разрешать. Я сталкивался с этим в ROS 2, 3 и, кажется, даже 4-й версии. Позже я просто взял стандартную конфигурацию, поэтому не знаю, когда произошло изменение. Интересно, почему MT сделал тут исключение? И спасибо за ваш очень подробный ответ.
22.01.2019 21:58:00, sebastia.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421993 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421993 Tue, 22 Jan 2019 21:58:00 -0500 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
Снова: клиент DHCP не может быть заблокирован с помощью ip firewall. Только в бриджевом файерволе.
22.01.2019 20:19:00, nescafe2002.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421992 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421992 Tue, 22 Jan 2019 20:19:00 -0500 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
DHCP работает поверх UDP и МОЖЕТ блокироваться файрволом, поэтому ЕГО НУЖНО разрешить, иначе он не будет работать… Подробнее о протоколе — https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

В контексте исходного вопроса, MT разрешает первоначальный DHCP-запрос с порта 68 на 67 по UDP, а правило «разрешить установленные/связанные» обрабатывает ответ.  
Правка: исправлено в соответствии с текущей ситуацией.
22.01.2019 15:11:00, sebastia.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421991 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421991 Tue, 22 Jan 2019 15:11:00 -0500 RouterOS правила брандмауэра для интерфейса WAN — правила брандмауэра DHCP без эффекта RouterOS в форуме RouterOS.
Привет! В дополнение к этой теме (все еще не решено) — **http://forum.mikrotik.com/t/no-firewall-rules-for-dhcp-renewing-for-wan-interface-dhcp-parameter-list/92680/1** — хочу задать тот же вопрос снова. Когда на моём тестовом роутере с ROS 6.40 мои правила файрвола блокировали весь трафик WAN, порт WAN не мог получить IP от провайдера. Но в ROS 6.42.9 и 6.43, которые я тоже проверял, порт WAN может получить IP, даже если мои правила файрвола блокируют весь трафик на этом интерфейсе. Я заметил такое странное поведение, потому что у меня есть правила для WAN, которые считаются и по обновлениям DHCP. И в ROS 6.42 счётчик остаётся на нуле, но IP всё равно присваивается. Также UDP-соединения отображаются в списке соединений. Как такое может быть, что порт WAN получает IP от провайдера, хотя весь трафик заблокирован (возможно, сервис файрвола загружается слишком поздно при старте)? Есть ли скрытые правила или даже ещё более скрытые правила в новых прошивках? Большое спасибо!
18.10.2018 12:20:00, onlineuser.]]> http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421990 http://mikrotik.moscow/forum/forum57/87954-pravila-brandmauera-dlya-interfeysa-wan-_-pravila-brandmauera-dhcp-bez-effekta/message421990 Thu, 18 Oct 2018 12:20:00 -0400 RouterOS