Avoid those that talk in riddles LOL…
Case in point, you DONT want to end up like this… dog pukes on config → https://forum.mikrotik.com/viewtopic.php?p=1142057#p1142017
OK, so after some testing everything seems to be pretty darn good with this so for the time being I will leave it like this. Everything seems fine and both LANs seem isolated from each other. Thank you both for your help. I’m not easy to teach and learning a completely new thing is daunting. Thank you for your hand holding and dumbing down so even I can understand it. Amazing how you can get pretty good with one thing like the zyxel and then know be so lost with the new thing.
I have a next question but I think I will break it off into a new topic since it’s a new topic. Thanks.
I have a few more questions about my set up. Let me first state that I created 2 firewall rules; 1 blocking all traffic from lan1 to lan2 and another one doing the same thing in the other direction. Just in case that has anything to do with what I’m about to ask, as I have a feeling it might.
-
Interfaces-> interface list
By default there are 2 listed; LAN & WAN. LAN has the default configuration bridge which I did not touch, only to remove the 2 ports for the new bridge. So do I need to create a new interface for the new bridge I created? -
DNS server? Gateway?
So I created a second LAN (LAN2 - 192.168.2.x) and, as usual, it says that the gateway is 192.168.2.1. Is that OK? Is it functional? Is there a DNS server at that address? LAN1 which has default 192.168.88.1 as gateway seems to be a little faster getting pages. Could it be that LAN2 is going to 192.168.2.1 and getting no reply and then having to go to the secondary DNS? Do I have to set up a DNS server or some other setting on LAN2 to be correct?
Could the fact that ALL traffic from LAN1 to/from LAN2 is being dropped mean that any DNS queries to 192.168.88.1 are also being blocked? Do I have to create a rule that allows DNS to go from LAN2 to the server on LAN1 192.168.88.1?
edit: I just noticed that on IP-> DHCP server-> networks tab the LAN2 network is there BUT the DNS server field is empty as opposed to the same field for the default 88.0 LAN1. Should there be a server listed in there? Should it be 192.168.2.1 OR 192.168.88.1? And if so then I would need a firewall rule to allow that traffic right?
- interface list Is a categorization, you are telling that (say) ether1 belongs to “group” WAN and that bridge belongs to LAN. These interface lists are used - as an example - in /ip firewall filter and /ip firewall nat to apply the same rule/commands to all members of the list (or “group”).
So yes, you need to have both bridges as LAN to have many of the default firewall and nat rules work the same as the original also for the added bridge. - 192.168.2.1
Interface lists are handy things.
They are used in different parts of the config.
Think of using them as a way to describe one or more interface ( normally vlans once gone down the path of using vlans).
The default interface lists are well understood, WAN and LAN.
One can make any sort of LIST one needs, typically TRUSTED or MANAGEMENT is common.
Mostly used for firewall rules to describe users that require traffic in some direction.
Rules of thumb for firewall rules:
…if its two or more interfaces create an interface list. ( exception is management interface which may be one vlan/subnet)
…if its a single device or subnet simply use the dst or src address x.x.x.y or x.x.x.0/24 respectively
…if an identification of users consists of an number of users but not all, or users from different subnets USE Source Address LIST!
(this applies whether or not there are SUBNETS involved, so any mix of of the above and full subnets would be best described as a source address list.
As for rules to block traffic between subnets, you have the backwards approach.
Attempt at all possible to allow identify needed and allowed traffic
Last rule in a chain is drop all else
..
And, to add some context, these are the default firewall rules (for Soho devcices):
http://forum.mikrotik.com/t/buying-rb1100ahx4-dude-edition-questions-about-firewall/148996/4
This one:
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
uses the ! to select as in-interface ALL interfaces that are not LAN, so you need the second bridge to be LAN to access from it the router.
- Once I saw that I kinda thought it should be so thank you and I did it.
- I presume you mean that 192.168.2.1 is the gateway DNS server for LAN2 and so I should put it in IP->DHCP Server->Networks DNS server field for the network of LAN2 that I created and for some reason left out before.
I did try that before creating the lan interface for lan2 in the intefrace list and it didn’t work at all. As a matter of fact before it was slow DNS and after it was completely broken. My assumption is that because it didn’t have the interface thing it was just failing completely and not dropping back to secondary DNS any longer. However after adding the LAN2 interface to the interface list and then placing 2.1 as DNS server it is now working and as fast DNS as LAN1.
So I’m learning a lot here. Probably for nothing because in the end I’m probably going to scrap it all and do the VLAN thing, but I guess no such thing as useless knowledge and I have the time and so far at least I’m enjoying learning so let’s continue 
With regards to setting up the correct firewall rules… On each rule there is a checkbox called “log” which I think is safe to say that it will log whatever that rules does, right? So probably best to create a rule and allow it to forward and log so you can see what it does before changing it to drop, right?
So right now, as in my old Zyxel, I created a last/final rule to drop everything and log it. Right now I have it set to allow and log to see what it does. My assumption was that it would log nothing since all traffic should be filtered by that point, but it’s actually logging quite a bit so I might have to tidy things up before enabling a rule like that as Anav stated a few posts back. I’ll check out the logs and see if I can understand and then post my questions.
If you are going to fiddle with the firewall, remember that rules are applied in the order they come within the same chain, so it is a good habit to keep firewall rules by chain, usually first input, last forward (a standard firewall has only input and forward chains) so that the settings are more readable.
Much easier to spot errors when your firewall rules are within the same chain as well!!
Also for interfaces you could make one for all subnets that need internet, or need access to a printer or whatever you fancy.
Its a matter of creating interfaces or firewall address lists for efficiency and clarity in firewall rules.
For example in the rule jaclaz noted. ( I dislike it by the way ),
add chain=input action=drop in-interface-list=!LAN comment=“defconf: drop all not coming from LAN”
Its needlessly confusing and at the same time is not the best security approach because one is saying block anything not coming from the LAN.
I prefer focussing on rules that speak to what traffic is allowed and block all else…
add chain=input action=accept in-interface-list=LAN comment=“lan to router services”
add chain=input action=drop comment=“drop all else”
Once you figure out that only the admin should have access to the router this quickly turns into
add chain=input action=accept in-interface-list=TRUSTED comment=“admin config” { could further limit by a source address lists so not an entire subnet }
add chain=input action=accept in-interface-list=LAN comment=“users to router services” dst-port=53 protocol=udp
add chain=input action=accept in-interface-list=LAN comment=“users to router services” dst-port=53 protocol=tcp
add chain=input action=drop comment=“drop all else”
@xsentinel
You’ll have to take some time to go through this loooong thread:
http://forum.mikrotik.com/t/firewall-rules-analysis/181836/1
to better understand the two different usual approaches in firewall.
or not and simply accept its far easier to know what traffic is needed vice all the ways traffic can possibly circumvent firewall rules.
Allow what you want, drop the rest is as clear and as simple as it gets, anything else is just noise…