Anyway, maybe this doesn’t even make sense, but I want to have different internal subnets have their own NAT rule to the outside world, but it seems this is not possible. I get a popup which says this :
mikrotik couldn’t add nat rule - incoming interface matching not possible in output and postrouting chains
I’m trying to set up for a given interface. My full config is at the bottom of that other linked thread.
Hello, OP and welcome to the forum. I have read your thread about the dedicated management port with interest. Mostly not for the topic itself, but about how someone coming from other vendors’ solutions gets along with MT’s philosophy (and Linux firewalling in general). I found it entertaining - if that is disrespectful, I really don’t mean it that way.
As to your question. It is very much possible to match the in-interface (and alike) things in srcnat/masquerade rules. However it was only introduced relatively recently:
What’s new in 7.18 (2025-Feb-24 10:47):
*) firewall - allow in-interface/in-bridge-port/in-bridge matching in postrouting chains;
This leads me to some rambling about things in general. If you are fairly new to Mikrotik (only an assumption), it would generally be best to do your experimentation on a fairly recent version. I would suggest 7.18.2, others will suggest the latest 7.17, etc. - but generally Mikrotik continually fixes things and getting stuck on an old bug makes little sense. Also, new releases sometimes contain subtle breaks and I also wouldn’t use them for initial experimentation (unless of course they contain something new or a fix that is particularly relevant tp you) until possible bugs have surfaced or discussed on the forum.
The fix you were provided with regarding matching on the src-address attribute is an interesting one to discuss. It fixes your problem and in a perfectly healthy way.
More generally it is worth having a look at why things are the way they are. It is not an accident it was not available in the kernel used in v6 (so it’s a relative newcomer to the otherwise very stable netfilter things that drive the MT firewall). In fact its unavailability was why it was forbidden in the MT implementation. I think it also raises the question that given its availability in the v7 kernel, why was it added so late. The reason is that it is not generally used. The dstnat processing happens early (close to when a packet is received) and here in-interface is common, and actually out-interface is forbidden; srcnat occurs very late in processing, right before releasing the packet to the out interface, and therefore it is quite common to use out-interface type matchers, and although the in-interface information is available technically it isn’t really used. Why? Now this is the gist of the issue.
Srcnat rules rewrite the source address, so the natural criterion is “what address(es) should I rewrite?”, similarly for dstnat, where the destination address is rewritten, the natural question again is “what address(es) should I rewrite?”.
So actually what I’m saying in a very convoluted way is that not only is using the src-address matching a workaround, but actually it is better. In the default rule that you based yours on, the appropriate criterion would be: rewrite everything i.e. 0.0.0.0/0, and thus the criterion was omitted. But it’s best to base your modification on that assumption.
As an (another) aside, using address lists is very much preferred (even if they only contain one subnet or even a single address). They give you a way to change things around easily and also give a self-explanatory nature to your rules.
The default firewall rules as written are absolutely fine, however they are intentionally succinct, and therefore don’t provide the very best basis for refining them into a fuller system of rules. I usually use a functionally equivalent but much more verbose configuration as starting point.
EDIT: Just another aside: you can actually simulate the in-interface behavior in earlier versions with marking the packet in prerouting based on its ingress interface and then using the packet mark matcher in the srcnat rule. This is basically only of academic interest - I don’t think anyone would actually want to do this.
@loloski - Makes sense to me (sorry for a short version, I fell asleep on the previous post ) @OP keep in mind that sourcenat still requires one to ensure firewall rules allow traffic and routing provides a path for traffic to get there, neither of which is the purpose of sourcnat.
The best way for me to learn is for you to elaborate on this. Yes I am new at MT and at Linux firewalling in general. What sort of philosophical assumptions am I making that are incorrect for MT?
I’d be very interested in seeing this.
Also I’m writing up a longer post that I will post this weekend about all the gear I have and asking what is the best approach to go about configuring it. It sort of goes along with my first quote above.
Regarding the latest release - I went into “System”, “RouterBoard” and it has 7.8 and could not find anything more recent. That didn’t seem right so I was going to ask about it. I have network connectivity so it should be able to call home.
RB5009UPr+S+
Thanks others for your responses I’ll start working with address lists.
First of all: I really mean it that you should use some relatively recent software version. (Though not necessarily the newest.) The routerboot firmware images are included in the base package of the software, but by default they just sit around - so there is no need for any sort of online-ness or separate download to obtain them.
To upgrade routerboot, you simple use system->routerboard upgrade. For this to take effect, you will need to reboot.
The versioning of routerboot is a bit interesting. Quite a while ago MT decided to version routerboot together with routeros, which effectively means that a new version of routerboot is issued with each release even when there is no change outside of incrementing the version number.
The recommendation is to always run the routerboot corresponding to your software version.
Just with an outlook to the latest buzz: The steps I described here don’t touch the backup bootloader. That should be left alone unless there is some very good reason to update it. That is exactly why there are special packages / special instructions in the few cases where it may become necessary, therefore there are no “special” steps to take to avoid changing it: if you don’t go out of your way to mess with it, it should be safe. The backup bootloader provides the netinstall facility, and basically allows the device to be recovered from even drastic messes.
My assertion is not that people (you in this case) have bad assumptions, it’s more that I’m quite certain that network vendors in general do their best to intentionally mislead people. Most everyone uses networking equipment, but (as with basically everything in life) 99% of them don’t really want to understand them, but just have them work, be easy, etc. Their goal is not to understand stuff - the network is a means to accomplish a task that they want to do, and when it doesn’t work they therefore quickly become frustrated. The common phrase I hear from people (even professionally, even from engineers) is that “I just simply want it to…” and well, there’s a bit more to it than that. Vendors are all too happy to cater to this mindset with reassuring marketing and interfaces: just take a look at the website of the favorite MT competitor (UBNT) or a relatively newer product Firewalla to see this - and both their stuff actually works pretty well as long as you “color within the lines”.
One of the assumptions that you make is that there is such a thing as a “management port”, which isn’t really a thing in the Linux/BSD based networking devices. (For the higher-end devices where there is actually a data plane-control plane separation in software/hardware it makes very clear sense.) Most devices “simulate” this using appropriate features, such as firewalling, namespaces, vrfs. At its simplest the question should be approached as a question about firewall configuration, not some magical concept or feature.
The same is true for “trunk port”. A very nice and well educated guy I helped recently with setting up a trunk port, when I’ve already helped him, and we’ve successfully set up the trunk port, and he understood every step along the way asked three or four times “okay, and where do we set it to trunk?” - and only then accepted that being a trunk port is just a concept, and we’ve just implemented it.
This is the sort of thing I was referring to.
Well… I don’t actually have the base written out. I think it would be more useful if I’s just take the default configuration as say where I think it could be better/clearer:
The first thing is that I think the “input” and “forward” chains should both be terminated with a “drop all” rule, that is: a drop rule with no matchers. Everything that is allowed should be to have al allow rule before this one. This doesn’t mean that these rules have to e overly specific, just that they should be clearly identified. Mikrotik has the “default policy” of “accept” - meaning that anything that falls through the firewall is accepted. I think that for the input and forward chains this is not good practice - in effect this changes the default policy to deny. It basically comes down to specifying who has access to what instead of blocking specific traffic that we don’t want. The latter is a very hard target.
So the rules:
(1) is mostly okay. I just have the problem with it that it assumes that anything that is “untrackes” should be allowed. Sometimes this is the case, sometimes not. I don’t think it belongs there.
(2)-(3) are okay.
(4) is basically for loopback packets. For some versions the “lo” (loopback) interface is exposed. It shouldn’t use an address based matcher, but in-interface=lo
(5) is just formulated counter-intuitively. Just accept everything from LAN, then add a rule to drop everything else. No need to be so frugal with rules - they’re cheap.
Here, instead of allowing LAN to access every service on the router, I usually expand on the different services, creating a rule for each of them. Do they have access to DNS? NTP? SSH? telnet? webfig over http? https? ftp? winbox? api? api over ssl? - I think these should all be tailored to your specific application and not indiscriminately exposed.
(6)-(7) are specific to ipsec, and allow everything that comes in or goes out encrypted. Maybe this is what you want, maybe not. Note that there is no similar rule in the input chain, which means that even though the other side of the ipsec connection has access to everything on your network, it can’t access the router’s management interfaces… doesn’t make all that much sense.
(8) I view fasttrack as an optimization. For initial configuration I usually don’t use it. (Half the threads here about how to debug a firewall begin with “have you tried disabling fasttrack”…)
(9) again with the untracked
(10) okay
(11) with the new “drop all” rule at the end this would become: allow everything dstnatted. This is actually sensible: for dstnat, the admin has already made a rule to selectively match the traffic - probably they want it to go where its address was rewritten.
Also, before the “drop all” in forward we have to allow what has in the default fallen through as thus was allowed: “allow in-interface-list=lan”
(12) is okay. My only quibble is with the ipsec exception. In many scenarios it makes sense to except ipsec traffic from NAT (or handle it in another way) - if you want this just add an “accept ipsec” above it, or another more specific NAT rule if that’s desired.
Sorry for the long post, but I actually have wanted to write a detailed critique of the built-in firewall.
I would like to reiterate that the default firewall is correct and well written in the sense that the main goal was not: “here’s how you build a good SMB-Enterprise style firewall”, rather to provide - by default - a firewall that offers an equivalent protection to off-the-shelf devices that you would pick up elsewhere. This it does fully and well.
My own take on the perfectly fine ( but confusing ) default firewall for most of the non high end routers is that it should look like the following.
Clear rules without any ! associated rules needed and most new user will be using wireguard not ipsec. THis should be the standard ruleset for one bridge, single LAN on all ports.
/ip firewall filter
{ default firewall rules to keep } (1) add chain=input action=accept connection-state=established,related,untracked
(2) add chain=input action=drop connection-state=invalid
(3) add chain=input action=accept protocol=icmp
(4) add chain=input action=accept dst-address=127.0.0.1
(admin firewall rules) > (5) add chain=input action=accept in-interface-list=LAN comment=“accept LAN traffic for configuration and dns etc.”
(6) add chain=drop action=drop comment=“drop all else” { place this rule in this location but last of all rules }
+++++++++++++++++++++++++++++++++++
{ default rules to keep } > > (7) add chain=forward action=fasttrack-connection connection-state=established,related
(8) add chain=forward action=accept connection-state=established,related,untracked
(9) add chain=forward action=drop connection-state=invalid comment=“defconf: drop invalid”
(admin rules) > (10) add chain=forward action=accept comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN
(11) add chain=forward action=accept comment=“port forwarding” connection-nat-state=dstnat disabled=yes { enable if required or remove } (12) add chain=forward action=drop comment=“drop all else”
It is very easy now to add complexity to the config and modify the firewall rules accordingly. For example, introduce the concept that only the admin should have full access on the input chain but the users might still need access to DNS or NTP for example. add chain=input action=accept in-interface-list=MGMT comment=“admin access” { could be limited further to a subset of IP addresses only by source address list }
add chain=input action=accept in-interface-list=LAN comment=“users to services” dst-port=53,123 protocol=udp
add chain=input action=accept in-interface-list=LAN comment=“users to services” dst-port=53 protocol=tcp
add chain=input action=drop comment="drop all else"
If one introduces another subnet on one of the ports that is not on the bridge or vlans, then any needed connectivity is added between them as the default drop all, takes care of any unwanted traffic, its built in.
)