I have 2 bridges created. One for primary use and the other for guest.
I have two wlans to match each bridge.
All traffic seems to be allowed between each of the segments,vlans.
I have no policy allowing guest network to access the primary network in the firewall however its still allowed.
I have even tried adding a blockrule.
Is there something I am missing?
By default, routers will route between all of its IP interfaces. If you want to prevent it, you have to use firewall filtering. Something like this:
/ip firewall filter
add chain=forward action=deny src-address=first.ip.sub.net/24 dst-address=second.ip.sub.net/24 comment="No routing between subnets XX and ZZ"
.
Remember that rule order (inside same chain) is important, first rule that matches, gets executed.
I have the exact same scenario. I place these rules after the accept Forwarding chain Rules and more specifically right after the default Forward chain Drop rules for INVALID and FROM WAN not DSTNATed.
Not sure if deny is better than drop, I tend to use drop.
Bridges are great in that they stop layer 2 traffic cold between them but the router can still route between them at layer 3 and thus one needs to put in Block IP Filter Rules.
You will see that I have two rules, one has to block in both directions!!
for the forward case. I use the in-interface: BridgeNAME for the origin of the traffic, so below I block DMZ to HOME and thus the in-interface is the DMZbridge etc…
homelan-bridge1
dmzlan-bridge2
/IP
Firewall Filter
add action=drop chain=forward comment="Block DMZ to LAN" dst-address=\
192.168.0.0/24 in-interface=DMZ_Bridge src-address=192.168.2.0/24
add action=drop chain=forward comment="Block LAN to DMZ" dst-address=\
192.168.2.0/24 in-interface=HomeBridge src-address=192.168.0.0/24
What I would like to know is if there is a better way to do this?
- Is my in-interface identification OVERKILL and not needed since I also state source and destination subnets???
(I put in-interface because it helps me visualize where the traffic starts and thus which interface it touches first).
Is use-ip-firewall=yes for both bridges?
I don’t know which device is being used but if it’s not a CRS you’ll only get hw-offloading on 1 of the bridges and you’ll see high cpu usage, this is better done using vlans (Correct way to divide layer2 networks) since right now it’s like 2 separate networks on individual switches joined by a router with all untagged traffic.
After that you should be able to apply firewall rules as you’ve been doing it with the change that you’ll be blocking traffic from dmz_vlan or lan_vlan.
/ip firewall address-list
add list=VLAN address=192.168.10.0/24 comment="VLAN: 10"
add list=VLAN address=192.168.20.0/24 comment="VLAN: 20"
add list=VLAN address=192.168.30.0/24 comment="VLAN: 30"
/ip firewall filter
add chain=forward action="drop" comment="No inter-VLAN routing" \
dst-address-list=VLAN src-address-list=VLAN log=yes log-prefix="InterVLAN"
Multi-directional, L3, inter-VLAN traffic block with one IP firewall filter rule using address list.
@anav: Any evil hacker can easily send packets with forged source, but they can’t forge incoming interface.
If I connect to your DMZ_bridge, I can send anything to HomeBridge, as long as I use some other source than 192.168.0.0/24. Sure, it will be limited, I won’t be able to establish tcp connections, but if you happen to have house’s udp-controlled self-destruct button connected to HomeBridge, you might have a problem, if it wouldn’t have own properly configured firewall.
This is the reason, why I prefer to block everything by default and add exception to allow stuff. I’d say it’s harder to get it wrong. If I make a mistake and forget to allow something, I’ll immediately see that it doesn’t work. If you make a mistake and forget to block something, it’s not that obvious. You may do the testing with something that the rule will block, but if it fails to block something else, you might never notice.
Hi Sob, you amaze me at your consistent and skilled ability to avoid my questions, make comments on my configuration that are puzzling and in the end leave me with a bitter taste and unfulfilled aspirations…
But since I know the response is suck it up princess… 
Lets get to it.
-
So are you saying my addition of in-interface is worthwhile and a good idea in addition to identifying the LANs
-
Do you like squeeze’s idea of putting on all LANS and VLANS on one address list and then using that list as source and destination and putting block?
-
If you concur with 1 and like 2, but the problem here is one cannot do both at the same time sobchain=conundrom
-
Okay how do you propose BLOCK is default and allow is the exception in this case?? ko,
Oh no, I’m trying to answer a lot of your questions. It’s just that you often have very long posts, and I may sometimes fail to pick up what exactly you were asking about. I mean, I think that I usually know, and I try to tell you what you wanted to know (even though in some cases you didn’t know that you wanted to know exactly that). Not necessarily each individual question, because if I did that, I’d be really writing a book. Trust me, I tried. English is not my native language and I did believe that I know it enough to express pretty much anything related to computers and networks. Trying to reply to some of your posts did shake this belief of mine.
About the current batch:
- More like that when you really want to isolate two interfaces, use just in/out-interface and it will stop everything for sure. If you use src/dst-address (alone or together with interfaces), some unwanted traffic can still pass.
- Not too much (sorry squeeze), because it has the same problem. If I connect something to physical vlan 10, I may be able to send some traffic to other vlans, if I use fake source address (e.g. 192.168.66.6).
- Original post looks like it may be simple home setup with main LAN and guest LAN, so I’d do e.g.:
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=drop chain=forward
And there’s no way how anything can sneak between main and guest LANs. If I later add VPN to some super-secret company network, nothing will be able to access it, until I add another accept rule. I will notice immediately on first attemp to access it that I need to add the rule. Compare it with:
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=drop chain=forward in-interface=WAN connection-nat-state=!dstnat
add action=drop chain=forward in-interface=mainLAN out-interface=guestLAN
add action=drop chain=forward in-interface=guestLAN out-interface=mainLAN
If I add VPN connection to super-secret company network with this config, all guests will be allowed to access it, until I add another rule to block them. And it’s easy to miss, because they (guests) won’t be complaning about having acccess where they shouldn’t.
Very interesting!!
So the two difference I can see is that
-
you have two rules explicitly detailing where forward traffic from the LANs/VLANS can go
Instead of having two rules stating the router should block traffic from A to B and from B to A. -
you remove the forward chain DROP rule for in-interface wan traffic not DSTNATed.
because you have a more powerful catch all rule Everything else forwarded - drop.
Okay, but why is this not the HEX default setup on the forward chain side then?
/ip firewall filter
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN ( the default 192.168.88.0./24 LAN on etherport2) and wan on etherport1)
add action=drop chain=forward
It’s hard to make everyone happy. I like block-by-default config better, but it’s just one opinion. I think it’s safer, but someone else might see it as annoying. Default config needs to find the right balance, be reasonably safe but not obtrusive. Current default config makes you safe from unwanted stuff from internet, that’s the most important part. And when you add another LAN/VPN/etc, things “just work”. With block-by-default config, they wouldn’t. At least it would look that way to many people, some might even think that the router is broken, flood support with questions or complaints, …
I whole-heartily endorse @Sob’s approach of BLOCK by default config — it is MUCH safer!!!
I liked your idea Sob, and since I already had implemented Drop By Default on the more security-sensitive Input chain (only allowing DNS and ICMP Echo Request from LAN), I decided to implement it for VLAN interfaces on the Forward chain.
Still, I was interested to see if another List method would work.
/interface list member
add list=VLAN interface=vlan10
add list=VLAN interface=vlan20
add list=VLAN interface=vlan30
/ip firewall filter
add chain=forward action="drop" comment="No inter-VLAN routing" \
in-interface-list=VLAN out-interface-list=VLAN log=yes log-prefix="InterVLAN"
Tested it and using interface lists also works. That way an explicit block cannot be IP spoofed!
You deserve a squeeze for that gem of an idea!!
SOB Based approach, but for dummies guide…
Getting close?
/ip firewall filter
{INPUT}
add action=add-src-to-address-list address-list=Port_Scans \
address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
protocol=tcp (or udp)
add action=drop chain=input comment=PREVENT WinBox Intrusion except for those on allow list" \
dst-port=8291 protocol=tcp src-address-list= !allow
add action=accept chain=input comment="Accept established
and related connections" \ connection-state=established,related
protocol=tcp
add action=accept chain=input comment=\ ALLOW list admin access to Router (all ports)
\ src-address-list=allow
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"
{FORWARD}
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
ipsec-policy=out,none out-interface-list (assuming two WANs)
/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
dst-address-list=blacklists or country lists etc..........
COMMENTS/Qs
WHY DO WE NOT HAVE UNTRACKED IN THE ACCEPT RULES For Input and Forward, as they are included in the Mikrotik Default Rules??
WHAT ABOUT DNS
WHAT ABOUT ICMP
@squeeze: In case the interface list is supposed to contain all vlans, it would be possible to skip it and use the magic “all-vlan” value (in-interface=all-vlan out-interface=all-vlan).
@anav: You don’t need extra WinBox blocking rule, because you open its port only to admins and connection attempts from elsewhere will be dropped by last rule. Port scanning rule should go after accepting established connections, because what it looks for will have connection-state=new (or perhaps invalid). If it’s first, you’re wasting (a little bit of) resources on checking packets that will be allowed by established rule anyway, just a moment later. And you don’t want to limit established to tcp only.
I keep forgetting about untracked, because it’s relatively new in RouterOS and nothing becomes untracked unless you tell it to be (in raw), so if you don’t do that, you don’t need to allow it, because there will be none.
If you’re not aiming for super-secure, I usually allow any input from LAN, because I trust it. If you don’t, you can allow only tcp/udp 53 for dns (from LAN only, definitely not from WAN, it would make the router open resolver).
About icmp, I don’t belive that being “invisible” by blocking icmp makes you any more secure, so I allow it. But opinions differ, some people think that it’s good or even important. And in a way they are right. In theory it’s possible that someone discovers a nasty bug that allows to bring the router down by sending a special icmp packet. It’s highly unlikely, but not completely impossible. If that ever happens, icmp blockers will laugh at me and say “we told you!”, but until then I’ll enjoy the advantages, e.g. being able to quickly see if the router is alive, no matter where I’m currently connected.
See bold comments above!
I cannot actually see any interface called “all-vlan” anywhere in Winbox nor in the online documentation. Would be very convenient if it did exist!
@anav: From top:
-
No. Just that if the list is supposed to contain all vlans on router, there’s simpler solution without list.
-
Yes.
-
Correct. If you don’t use it, you don’t need to allow it.
-
I meant when you use router as resolver, so chain=input. What I do when I trust whole LAN is simple:
/ip firewall filter
add action=accept chain=input in-interface=LAN
And it allows access from LAN to anything on router (DNS, WinBox, …). If you don’t want all that, but only DNS, then use:
/ip firewall filter
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
You generally don’t need drop rules when there’s unconditional drop rule at the end of input chain (it drops everything not previously allowed). It goes for both input and forward.
But there’s one thing I forgot, if you have drop rule at the end and you want forwarded ports to work, you need to allow them:
/ip firewall filter
add action=accept chain=forward connection-nat-state=dstnat
- Yes.
@squeeze: I’m too lazy for screenshots, but this is what autocomplete suggests in CLI (WinBox has the same, only without hyphen):
[sob@CHR4] > ip firewall filter add in-interface=all-
all-ethernet all-ppp all-vlan all-wireless
You’re right, it doesn’t seem to be documented, I only found it mentioned in RouterOS v6 news.
So to confirm you are saying we don’t really need to state untracked (a very rare case only under our control - would require additional rules)
The untracked state is usually set in RAW or in… MangleRules 
Once a connection has been marked as untracked, all packets related and established in that connection will completely bypass connection tracking in the router. This means that any services on the router that rely on connection tracking (layer7 firewalls, fasttrack-connection, mark-connection, etc), any NAT rules, even packet de-fragmentation do not come in to play on those streams. So it doesn’t even go through the router to where firewalls have any control.
Okay new and improved Version…
/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept established
and related connections" \ connection-state=established,related
protocol=tcp
add action=accept chain=input comment=\ ALLOW list admin access to Router (all ports)
\ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"
{FORWARD}
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat**
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**
/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
dst-address-list=blacklists or country lists etc........
Questions??
-
What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp -
Do I need any special rules for DNS in forwarding???
-
Do I need any output rules, never seen one but what can be done here???