Hello,
I have a Mikrotik hEX RB750Gr3. I’m starting with the router reset with no defult configuration. I want to setup two seperate isolated DHCP networks (sub nets?) as shown below (network 1 = ports 2/3, network 2 = ports 4/5). I want network 1 and network 2 to be able to reach the internet conencted to Port 1, but I dont want network 1 and network 2 to be able to talk to eachother. I do not want to use VLANS. I’ve searched around a bit and find bits and pieces of how to do this but it’s not coming together for me yet partly because I dont know the proper terminology for searching what im trying to do. Is there a step by step guide for something like this using WinBox or a script that I could follow and modify? Any help would be appreciated. Thank you very much.
Desired Network:
Port1 = WAN with firewall connected to ISP broadband modem.
Network 1 (Home Network) : 192.168.17.1/24 with DHCP
Port 2
Port 3
Network 2 (IOT Network) : 192.168.18.1/24 with DHCP
Port 4
Port 5
A bridge spans multiple ports. So you’ll need two bridges, one spanning ether2 and ether3, the other spanning ether4 and ether5.
Bridges come with implicitly created interfaces, which are members of same bridge. These interfaces allow ROS to interact with subnet. So you assign IP addresses to those interfaces, bind DHCP server with appropriate pool of addresses, …
RB750Gr3, being router, will happily pass packets between its L3 interfaces (those with IP address set). If you don’t want some traffic to pass, you have to block it using firewall filter rules.
Now, in order to have decent firewall filters in place and overall decent base for making adjustments, I suggest you to reset router to factory defaults. Which comes with ether1 configured for WAN and the rest of ports bridged in LAN. Next you have to do these changes:
connect using ether2 or ether3
remove ports ether4 and ether5 from bridge
create another bridge (name it what ever you want, e.g. bridgeIOT) and add ports ether4 and ether5
add IP address to it
create DHCP address pool, DHCP network settings and bind DHCP server to bridgeIOT interface
This leaves default IP subnet (192.168.88.0/24) for your LAN. If you don’t like it, change it (and default DHCP server settings).
Next you have to add firewall filter rules which prevent talking between LAN and IOT. If you want to stay true to spirit of default firewall, you should create interface list called e.g. IOT and add bridgeIOT to it. Then add the following two rules to the end of firewall filter rules
If you want to allow connections initiated from LAN and not connections initiated from IOT, then disable (or remove) second rule and keep the first one.
If you’ll configure router for providing any services to IOT subnet (e.g. set router’s IP address as DNS server in DHCP server settings), then you’ll have to add some rules allowing access to those services for in-interface-list=IOT.
Which is default and then change remaining to this!!
add action=accept chain=forward comment=“LAN to WAN traffic”
in-interface-list=LAN out-interface=WAN
add action=allow chain=forward comment=“allow port forwarding”
connection-nat-state=dstnat connection-state=new in-interface=WAN {optional can be disabled or removed if not port forwarding}
add action=drop chain=forward comment=“Drop All Else”
The drop all else rules blocks all traffic not explicitly allowed.
Since you have only allowed LAN to WAN traffic that is what can occur.
Bridge to Bridge traffic will not be permitted.
I was bored, the Superbowl was so one sided LOL
Besides I thought you would be proud that I didnt use the word (sounds like a letter with a sharp point at the bottom and the word PAN)
Thanks again to anav and nkx for the very detailed helpful responses. I got it working and learned a lot along the way. This was exactly what I needed to go to the next level in my understanding about how routeros works. Thank you!
With regards to the firewall rules that prevent the networks from talking to each other, I used the rules below. After applying these rules things work as I wanted with the exception that computers on each network can still ping the gateway on the opposite networks. This is not what I expected, but may be normal. How would I prevent this too? Here is what it does with the below firewall rules…
Behavior I wanted and it works great:
Computer A (192.168.17.254) CAN NOT ping Computer B (192.168.18.254).
Computer B (192.168.18.254) CAN NOT ping Computer A (192.168.17.254).
Unexpected behavior on my part:
Computer A (192.168.17.254) CAN still ping 192.168.18.1
Computer B (192.168.18.254) CAN still ping 192.168.17.1
You may have been expecting packets from 192.168.17.254 to be received on the interface with the address 192.168.17.1, and these be processed by the forward chain to reach the interface with the address 192.168.18.1. Linux doesn’t work that way, IP addresses attached to any local interfaces are handled by the input chain, see https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter#Chains
You could add
/ip firewall filter
add action=drop chain=input in-interface-list=LAN dst-address=192.168.18.1
add action=drop chain=input in-interface-list=IOT dst-address=192.168.17.1
or not bother, packets destined for the ‘other’ gateway address will never been seen on the associated network.
anav,
I dissabled the rules from mkx (Rules: 12 and 13 below) and added your rules to the end (Rules: 14, 15, 16 below). I had to change “out-interface=WAN” to “out-interface-list=WAN” otherwise it would not be accepted. I also added Rule 15 below which is a duplicate of Rule 14 to allow the IOT interface to get to WAN. It seems to work the same as the mkx rules in that I can still ping the “.1” of the other interface. My goal is to isolate the traffice between each interface mainly so that the IOT devices dont have free reign of my home network. Maybe its ok that the each network can ping the “.1” of the other network since that is the gateway? I’m not certain what are the implcations of this from a secuirty and isolation perspective? Thanks again for your help!
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
1 ;;; defconf: accept established,related,untracked
chain=input action=accept connection-state=established,related,untracked
2 ;;; defconf: drop invalid
chain=input action=drop connection-state=invalid
3 ;;; defconf: accept ICMP
chain=input action=accept protocol=icmp
4 ;;; defconf: accept to local loopback (for CAPsMAN)
chain=input action=accept dst-address=127.0.0.1
5 ;;; defconf: drop all not coming from LAN
chain=input action=drop in-interface-list=!LAN
6 ;;; defconf: accept in ipsec policy
chain=forward action=accept ipsec-policy=in,ipsec
7 ;;; defconf: accept out ipsec policy
chain=forward action=accept ipsec-policy=out,ipsec
8 ;;; defconf: fasttrack
chain=forward action=fasttrack-connection connection-state=established,related
9 ;;; defconf: accept established,related, untracked
chain=forward action=accept connection-state=established,related,untracked
10 ;;; defconf: drop invalid
chain=forward action=drop connection-state=invalid
11 ;;; defconf: drop all from WAN not DSTNATed
chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN
12 X chain=forward action=drop connection-state=new in-interface-list=IOT out-interface-list=LAN log=no log-prefix=""
13 X chain=forward action=drop connection-state=new in-interface-list=LAN out-interface-list=IOT log=no log-prefix=""
14 ;;; LAN to WAN traffic
chain=forward action=accept in-interface-list=LAN out-interface-list=WAN
15 ;;; IOT to WAN traffic
chain=forward action=accept in-interface-list=IOT out-interface-list=WAN
16 ;;; Drop All Else
chain=forward action=drop
It’s what @tdw wrote: when packet arrives at some ROS interface, ROS first determines which chain to use. And if packet’s destination address is any of router’s own addresses (in-interface is not considered when determining chain, neither is src-address), it will be handled by chain=input regardless actual dst-address. Similarly on egress, e.g. when router itself produces outgoing packet (e.g. when running ping from router), it will first check with routing tables to determine out-interface, ant only later set src-address to the one matching out-interface. Unless you use src-address property of the tool.
And when packet enters certain chain, rules in other chains don’t apply. So if you want to block certain connections, you have to do it explicitly for each chain.
But, as @tdw already wrote, it’s not worth bothering, this is purely cosmetic issue.
Ahh I never see that phenomena as my input chain also had a drop all else rule at the end! (just make sure you have an admin access rule before it!!!)
Good to know (layer of MT and networking knowledge depth I will never have).
Ok so now I am also a bit lost, but once cleared up I suspect it will help me with this same behavior.
MKX suggested that the op use two rules like this to block inter network traffic…
filter add chain=forward action=drop connection-state=new in-interface-list=IOT …
filter add chain=forward action=drop connection-state=new in-interface-list=LAN …
Than OP came back and said it didn’t block pings between IOT & LAN netwroks.
Than TDW pointed out and MKX agrees, that the ping is in the input chain so would need to add rules like…
filter add chain=input action=drop in-interface-list=IOT dst-address=192.168.17.1…
filter add chain=input action=drop in-interface-list LAN dst-address=192.168.18.1 …
But my question is… if MKX’s original rule using the forward chain can’t block a ping between the two networks how does it block any other network traffic?
What am I missing in my understanding.
I made a post from yesterday(see my post) that is similar to the goals of the OP, except I created using a single bridge and two separate vlans, ether4 vlan40 & ether5 vlan50. I too am able to ping between the two vlans using a computer plugged into ether 4 and/or ether5, even after adding MKX’s original forward rule. Hence I suspect I too would need the filter for input chain per TDW. But before doing that I would like to understand how the mkx’s forward rule can block general traffic, but not ping. Doesn’t traffic sourced from a device plugged into either ether 4 and/or 5 fall into the input chain, rather than the forward chain?
It has been explained a few times before, but I’ll try to do it again. Packet passing router[*] in any direction are handled by chain=forward. Packets terminating in router[**] are handled by chain=input (note that name of firewall chain has nothing to do with internet versus LAN and perceived traffic direction commonly referred to as uplink and downlink, from networking point of view there are only subnets beyond interfaces, some subnets happen to be connected to other subnets via other routers (e.g. your ISP) and some are not (e.g. home LAN)). Router is part of both networks and since packets targeting any of router’s IP addresses are targeting same router, they are not really leaving ingress (source) subnet upon arrival at router. Hence logic that if router doesn’t block packet destined to “far” network interface of same router, it doesn’t block packets destined at hosts in other network as well, is not valid.
[*] Those are packets for which router has to perform routing decision. Most often these are packets entering through one interface and exit through another interface. But it doesn’t have to be two different physical interfaces, it can be different VLAN interfaces serving different subnets. It can even be same interface if sender for some reason decided to use router as intermediate hop. It can even be due to router’s configuration (e.g. setting arp=proxy-arp with next hop’s MAC address set as static entry in MAC table).
[**] In this context all router’s own IP addresses are treated equally, it doesn’t matter which interface has which address set. “Location” of IP address (the interface associated with IP address) only matters in ARP procedures (router will respond with correspondong MAC address) and when selecting src address for new connections initiated by router after route for packet was already determined.
But for ingress packet it doesn’t matter if dst-address matches ingress interface’s “native” IP address or not. If dst-address is one of router’s own IP addresses, it is chain=input.
Type of traffic (e.g. ping vs. anything else) doesn’t matter either when deciding upon which firewall cgain will process packet.
Thank you mkx, that explanation help expanded my understanding immensely.
But just to check myself… the ping from an external computer on subnetA(ether4) to a gateway address on a different subnetB(ether5) established in the same router is kind of a special case because the target ip(router/gateway x.1) is internal to the router itself, hence it is treated as input chain. But if I had plugged a computer into subnetA and another computer into subnetB than a ping between the two computers would have been blocked using the forward chain because it passed through the router. Is that correct?
Again thank you.
I must admit that attempting to learn about networking & mikrotik has been a bigger rabbit hole than I initially anticipated.
