firewall rules for WAN interface - DHCP firewall rules without effect

RouterOS General
1

Hello,

in supplement to this thread (still unsolved) - **http://forum.mikrotik.com/t/no-firewall-rules-for-dhcp-renewing-for-wan-interface-dhcp-parameter-list/92680/1 - I want to ask the same question again.

When my firewall rules on my testing router with ROS 6.40 dropped the whole WAN traffic, it was not possible that the WAN port got an IP address from the ISP. In ROS 6.42.9 and 6.43 for example I also tested it and there the WAN port can assign an IP address although my firewall rules block the whole traffic on this interface. I noticed this strange behavior because I have rules for the WAN port which also counts the DHCP renews. And in ROS 6.42 I noticed that the counter stays on zero but the IP could be assigned. The UDP connections were also shown on the connections list.

How can this happen that the WAN port can assign an IP from ISP although the whole traffic is blocked (will be firewall service be loaded too late while starting)?

Are there hidden rules or even more hidden rules implemented on newer firmware releases?

Thanks, a lot.

2

Well, the firewall is L3, DHCP happens on L2 until the lease is ack’ed by the DHCP server.

dhcp discover goes from your WAN-facing MACaddress to ff:ff:ff:ff:ff:ff, that’s a L2 broadcast.
dhcp offer is L2 unicast from DHCP-server’s MAC to your WAN-facing MAC
dhcp request is L2 unicast from your WAN-facing MAC to DHCP-server’s MAC
dhcp ack is still L2 unicast, from DHCP-server’s MAC to your WAN-facing MAC.

And here’s the point your firewall starts to work.

I’m rather surprised that it ‘worked’ in 6.40.

-Chris

3

I have no explanation, but had the same issue and resolved it by creating a bridge for WAN and applying bridge filtering.


/interface bridge filter
add action=drop chain=input comment="Rogue DHCP" dst-port=68 in-bridge=bridge-wan ip-protocol=udp \
    log=yes log-prefix="[Rogue DHCP]" mac-protocol=ip src-address=!1.2.3.4/32 src-port=67

MT supports response to the IP (filter/raw) firewall not blocking DHCP packets:


This is made on purpose. Behaviour will not be changed.

4

DHCP is over UDP, and CAN be firewalled and NEEDS to be allowed or it won’t work…
See https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol for protocol details


In context of the original question, MT allows initial dhcp request from port 68 to 67 on UDP, and “allow established / related” takes care of the response.

Edit: corrected to current reality

5

Again, dhcp client cannot be firewalled using ip firewall.

2019-01-22_21-14-15.gif
Only bridge firewall.

2019-01-22_21-18-51.gif

6

Unfortunately you are correct.
And I say “unfortunately” because it doesn’t make any sense, and goes against logic, as the protocol is using UDP on top of IP, both normally handled by IP firewall.

Further, in the past it had to be explicitly allowed. I run into it in ROS 2, 3 and still (I think) 4. Later on I just took standard config over and so don’t know when the change occurred.

Wondering why MT made an exception here?

And thank you for your very thorough response :wink:.

7

There’s another discussion on the topic: http://forum.mikrotik.com/t/impossible-to-block-dhcp-server-by-design-or-bug/32434/1

I don’t understand why, but the behavior is reported, confirmed by MT and there is an acceptable workaround (use bridge filer).

Perhaps some documentation on this specific limitation would be nice.

8

Thx, indeed doc would be nice.

For fun of it, tried dropping in RAW table, but “no such luck” :wink:

9

Up to 6.40.1 it worked to filter DHCP requests on the WAN port.

On later releases I tried to enable the “use-ip-firewall” feature and added a rouge DHCP rule.

/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

This works partially.

But why did Mikrotik change this behavior.
dhcp_6.40.1.png

10

Hi,
I have come across your conservation as MikroTik has DHCP rule in its Advanced Firewall Tutorial and I wondered why but came to the conclusion that they forget to define the use case of this tutorial.
Reading this thread I feel that the use-cases should be clearly defined.

  1. DHCP Server is in the same broadcast domain
    It is as explained by cdiedrich in post #2
    The only to prevent DHCP misbehaviour is to add DHCP Snooping and DHCP Option 82 but it is not supported by all Switch-Chips otherwise you have to ensure traffic flows through CPU or to work with ACL rules.
    In case it is a software bridge (no hardware offloaded port), you can use Bridge Filter as shown in the Flow of Bridged Packet.
    Maybe http://forum.mikrotik.com/t/exact-steps-to-block-rogue-dhcp-servers/20839/13 helps as well.
  2. DHCP Server is not in the same broadcast domain
    So DHCP queries leave the broadcast domain and are routed, are on L3.
    IP-Firewall can block it (and only then).
11

In practical terms this often comes up because people are surprized that they can ping and get a response from interfaces that are blocked by firewall rules.
Case in point VLANX can ping the IP address of VLANY and vice versa and the sky is falling… NO.
Just expected behaviour for interfaces on the MT device. The VLAN L2 structure prevents any ACTUAL DATA passing between the vlans so not to worry on that front.
In addition blocking vlanx to vlany traffic by drop all rules or explicit rules also stops cold any data passing between the vlans at L3, is the sky falling… NO

Thus in conclusion, funny things do happen, for reasons explained by others, but who cares, at the end of the day, no data is passing between them which is the goal.

Happy “Gruntled” day