My MikroTik router acquires dynamic WAN IP from ISP even when I set input chain to drop all traffic from WAN and set output chain to drop all traffic to WAN. How is that possible? Such rules should be blocking all layer 3 packets to router from WAN and from router to WAN. That includes UDP ports 67 and 68 used for BOOTP/DHCP. If those ports are blocked, then how can router acquire dynamic WAN IP address from ISP?
Most likely (almost 100% certain) something wrong in your firewall (maybe other settings but I would look at firewall first) but since you do not show anything, it becomes a small problem for anyone to help.
Actually no. The firewall simply does not apply to the packets of the dhcp client.
This may sound strange, but in fact it is quite logical. The DHCP client must send and receive packets while the interface in question has no valid ip configuration. In this state it is not possible to bind a normal socket, therefore so-called “raw sockets” are used. The traffic to these does not go through the firewall.
Such is life. By the way this is exactly how all the usual DHCP clients behave under every Linux.
Bridge filters (ebtables) can be used to filter such packets should the need arise. (In practice it doesn’t.)
NOTE:
This does not apply to the ipv6 version of the protocol (nor to RA based SLAAC.) Uniformity of packet handling in this sense is one of the many reasons why ipv6 insists on link-local addresses.
Because DHCP use raw sockets. Here is some literature (from ISC DHCP but should also apply to MikroTik’s implementation).
https://kb.isc.org/docs/aa-00378
Pff … glad I left that 1% option open 
Thanks for the correction, guys.
Well almost 100 is often taken as 99.9%, you give yourself too much credit, leaving only 0.1% margin of error.
So the good news is it was an efficient amount of wiggle room. 
Netfilter does have RAW chain and I think MikroTik firewall has UI section to it. Is that how I should try to control BOOTP/DHCP WAN IP acquisition?
Are there any other parts of RouterOS that bypass Netfilter filter chains? DNS maybe?
I also noticed default firewall comes with only one rule for 127.0.0.1 address (normally dedicated to loopback interface) to allow CAPsMAN. I disable that rule because I do not use CAPsMAN at all. The router continues to work with that rule disabled without showing any discarded packets. There are no other firewall rules that mention 127.0.0.1 and none that mention “lo” (loopback) interface, but it hard to believe that RouterOS does not utilize loopback interface internally for non-CAPsMAN functions… Normally Netfilter filter chains can control loopback. Should I assume that in this case they do not?
Do you have /ip/dhcp-client active on your WAN interface? If you dont want to acquire an address you should be able to disable this.
This is more about understanding why it happens that way and learning how to control it, as well as, finding if anything else bypasses filters.
No, DNS is completely normal IP (UDP or TCP) service. It’s only DHCP that uses raw sockets.
As mkx said, of the usual services only DHCP is special.
Mikrotik does allow you access to the netfilter raw chain (/ip firewall raw) and yes, it can be used to filter DHCP packets. I can’t think of a practical use for this, but it is possible.
As a follow-up to this, I have a related question regarding the raw table, and what interfaces it is applied to.
It’s tested in a VM on 7.18.
Two cases using ONLY the following firewall rules :
/ip firewall filter add action=drop chain=input
/ip firewall raw add action=drop chain=prerouting
Case 1 Using ‘ether1’:
Winbox can still connect using the device’s MAC address. DHCP-Client still retrieves leases, and DHCP-Server still provides leases.
Case 2 Using ‘bridge1’: (Assign ether1 to a bridge with the following:)
/interface bridge add name=bridge1
/interface bridge port add bridge=bridge1 interface=ether1
/interface bridge settings set use-ip-firewall=yes
Winbox drops, fails to re-establish. DHCP Client/Server fail to acquire a lease. Firewall works as expected.
Any insight into this? If the conclusion is that raw is only used on bridges, that’s a consideration to make.
mac-winbox hopefully is not on the WAN anyway, but some clarification or further digging would be helpful.
You are really getting into this 
First of all: you should get the same result whether the interface is a bridge or a “naked” port. And indeed you will, if you turn off use-ip-firewall (as you should). The setting use-ip-firewall actually utilizes a feature of ebtables (bridge filter in Mikrotik lingo) to redirect bridged packets to through the IP firewall. (If you want to look deeper into this, it’s the “redirect” action provided by the ebtables-nft kernel module. Mikrotik only exposes this through the use-ip-firewall all-or-nothing option.) This has its rare uses, but normally it should be turned off. If you turn it off, you will get the same result in both scenarios.
I already gave you two answers. Both are correct. Let me try to rephrase/make them clearer.
- The DHCP client (and almost all server) implementations create raw sockets.
- The hook for raw sockets appears after bridge filtering (if there is a bridge), and before it is handed off to the netfilter (ip firewall) framework.
Therefore:
- You can only prevent a raw socket from getting to your packet (or sending packets) if you filter at the bridge filter (ebtables) level. (You are actually doing this if you enable use-ip-firewall.) If you want to do this, then it is necessary to include a bridge in your setup (for the bridge filtering to take effect), even if it is only a bridge containing one (non-host-facing) port.
- You can still match/filter the packet in nftables (the only sensible place being the raw chain), but the raw sockets “get to it” before the firewalling step, so you can still prevent some other program that binds to the interface/address/broadcast in the normal way from getting/sending such packets. As I wrote, I can’t imagine why someone would want to specifically do this…
(Hint: if you want to see this in action, create a rule before your drop-all rule in raw specifically for proro udp, dst-port 68 for the dhcp client test case, and watch the counter increase. Indeed the fw sees the packets and drops them. Too late to prevent your dhcp client from getting to it though.)
I don’t mean to be dismissive of your inquiries’ in any way, however if you will allow me some advice. You are digging into an edge case of the Linux networking stack, and you are at the point where you will have to turn to the LKML archives for help, or better yet: read the source code for the modules/features that were pointed out. Or just don’t obsess over this, and maybe return to the topic when you have mastered the use of all the normal firewall features. When learning networking from the usual sources one has the impression that things are neatly divided into layers/boxes that only touch at well thought out predefined interfaces. If you take out a magnifying glass, you encounter many edge cases and interesting interactions almost anywhere you look.
You know what? I didn’t know what I was looking for here, but this answer covered it and points to other resources to dig through. I don’t consider this dismissive in any way either. I’ve got further resources to dig into now thanks to this.
I do agree this is an edge case btw… Anyone deploying a Mikrotik can easily select which interfaces the MAC-Server (ping and winbox) are connected to, as well as what interfaces DHCP servers/clients are connected to.
I was originally concerned there may be some implied rules that allowed this traffic
To add to what @lurker888 wrote:
Winbox MAC access is another function which works directly with raw sockets … so it escapes IP firewall.
Unlike DHCP it’s possible to control Winbox MAC access by configuring MAC access under /tool/mac-server.
Yep. All the MAC-* (mac-telnet, mac-winbox, mac-ping) also use raw sockets. I consider the only correct configuration for these outside of a homelab setting to be either “none” or a single trusted port or vlan.
I don’t exactly get the point that @mkx makes. Probably just a misunderstanding on my part. For dhcp clients and servers, the interface is explicitly specified as part of their respective configurations. (Although I’m not privy to Mikrotik’s implementation, these are usually separately bound using the sockopt SO_BINDTODEVICE, see raw(7) and socket(7) )
Part of my testing procedure was moving the DHCP server and client configs around from interface to interface, between interfaces and bridges.
I didn’t find any cases where DHCP communications unexpectedly worked when applied to an interface other than one I was directly connected to.
I managed to get a shell in RouterOS and although the dhcp daemon claimed to listen on 0.0.0.0/0 (via netstat), it still respected and used ONLY the interface it was assigned to. (Can’t be applied to interface lists)
MAC-Server stuff will listen to interfaces defined in an ‘interface list’, not a specific interface.. so watch your interface list configs (and don’t run it on an untrusted network)
Raw sockets have several methods of specifying which packets are sent to them. For selecting devices, the one I mentioned, SO_BINDTODEVICE is the most ancient, nowadays IP_PKTINFO is the more usual. The struct for this is:
struct in_pktinfo {
unsigned int ipi_ifindex; /* Interface index /
struct in_addr ipi_spec_dst; / Local address /
struct in_addr ipi_addr; / Header Destination address */
};
netstat doesn’t show all the fields, especially because multiple filters (selectors) may be active at the same time.
This is Netfilter flow chart - https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks .
Some things that were said here show why I ask similar questions for each router maker. Every makes has its own implementation of some functions and deviates from common standards. For example IP Bridge Firewall (EBTables) redirection. It is very unusual for a router to redirect all traffic from EBTables to IPTables as a default for bridged non-WAN interfaces. Normally, there are no EBTables rules, but packets are still processed by EBTables before being processed by IPTables. Normally, only WAN interface is not processed by EBTables. I can only guess MikroTik disables EBTables for bridged interfaces by default as part of “Fast Path/Track” feature because EBTables processing is CPU-intensive.
So DHCP client can acquire dynamic IP before RAW chain processing on WAN interface? In that case DHCP does not go through any IP filtering at all and there is no way to control it unless you manually add a bridge to WAN interface and IP Bridge Firewall to control, assuming that DHCP client does not bypass EBTables, which is what one of posts above suggests.
I can’t understood why it is common practice for almost all router makers to have WAN interface without a bridge and as such, prevent layer 2 filtering on WAN. There are all kinds of EtherType hacks out there.
This leads me to off-topic question the answer to which nobody appears to know - how do IPTables deal with EtherType frames redirected or brouted from EBTables to IPTables if those EtherType frames are not ARP and not IP? IPTables can only process IP and ARP. What does it do with the rest of EtherTypes it cannot filter? Discard them?
Generally, I am in agreement with you that router manufacturers do shady stuff, mostly in order to be able to claim the highest speeds with the puniest possible CPUs. Let’s be clear, by shady I mean that what they actually do is undisclosed (very bad!) and generally, when reverse engineered (usually because of some problem), it turns out that their implementation is only mostly correct - also very bad!
Although I don’t agree with Mikrotik’s decisions on many fronts, this type of criticism does not really apply to them. They use a mostly vanilla networking implementation, and it actually does what all Linuxes do, and in the same way.
The area where this does not apply is fastpath/fasttrack, these are speciically there to enhance performance at the cost of features and granularity of filtering. I will not discuss here what exactly is lost for these configurations, but for me the most important aspect is: You can actually fully and totally turn them off.
Some of your points I believe are based on some misunderstandings and%or are subtly misstated. (Please disagree!) Allow me to go over them inline.
Yes. Please note that this shows only the parts of the networking stack relevant to netfiler, as title correctly implies. For example it explicitly does not discuss what happens to ethertypes other than ipv4, arp and ipv6. The diagram is correct, it is just limited in scope.
As said above: fully agree! If a company is mainly a hardware/device manufacturer, then please don’t tinker with the (extremely complex) linux networking stack! At least document what you are doing exactly! At least allow us to turn it off! (Even if it leads to loss of performance.)
I am a bit hopeful on this point. Both the US and the EU are waking up to the dangers of these custom firmwares. I hope this raised awareness may lead to some level of accountability becoming normalized in this sector. Oh well, one can dream.
It is unusual. The use case imagined for doing this is to do IP firewalling without proper routing setups. It is bad network design altogether.
Mikrotik provides this ability with the use-ip-firewall setting in the bridge settings part of its interface. Linux provides the same with the ebtables-nft kernel module ebtables redirect action.
To clarify some points:
- Mikrotik and Linux both expose the same functionality.
- Neither on Mikrotik nor on Linux is it the default. You have to explicitly ask for it.
Bridge filtering is not disabled for fastpath/fasttrack.
To clarify. There is also a feature (confusingly enough) named “bridge fastpath” which can only become active if no bridge firewall rules are defined. (So the opposite happens: when there is bridge firewalling to be done, the feature is disabled, not the filtering - which is IMHO correct.)
Also to clarify. When switching functionality is offloaded to a hardware swtich chip, software-based firewalling cannot happen to the packets that the CPU does not see. (In this sense for this traffic they are implicitly disabled.) The admin can choose to use the switch’s ACL features, of disable hardware offloading on (some or all) ports.
I would assume (somewhat narcissistically) that you are talking about my posts
To rehash:
- The hook for raw sockets appears after bridge filtering (if there is a bridge), and before it is handed off to the netfilter (ip firewall) framework.
I believe this is exactly clear on that when handling raw (Berkeley) sockets, ebtables happens, netfiler does not. (To be exact, the packet - at least on Linux - is also passed on to the default registered ipv4 handler, and eventually does transit netfilter.)
The netfitler diagram you quoted does not represent this hook, because netfilter is not concerned with it. (BTW its around the green “prerouting hook” stage, before reassembly)
Again the subtle misstatement. This is not Mikrotik-specific but a thing in every linux. As such it is widely discussed all over the Internet. (The topic is subtle so the signal-to-noise ratio is quite low - misunderstandings and incorrect explanations are abound.)
It’s the common configuration. I won’t defend it. As I already wrote: if you want to use ebtables, you have to create a bridge Kind of logical. The difference is that on Mikrotiks you can - many manufacturers don’t give you the choice.
You are rightly baffled. I think both of us could fill tens of pages easily with why redirecting from ebtables to netfilter is a really bad idea in general. That’s why I would advise against doing it. (It does enable some hacks, but you will feel the need to take several showers afterwards.)