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
Re: Splitting Ports into Seperate Isolated Networks
Just make two bridges, add these ports and make dhcp servers on each one. By default networks will see each other between bridges.
Bridge1
Network 1 (Home Network) : 192.168.17.1/24 with DHCP
Port 2
Port 3
Bridge2
Network 2 (IOT Network) : 192.168.18.1/24 with DHCP
Port 4
Port 5
Sent from my ONEPLUS A5010 using Tapatalk
Bridge1
Network 1 (Home Network) : 192.168.17.1/24 with DHCP
Port 2
Port 3
Bridge2
Network 2 (IOT Network) : 192.168.18.1/24 with DHCP
Port 4
Port 5
Sent from my ONEPLUS A5010 using Tapatalk
Re: Splitting Ports into Seperate Isolated Networks
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:
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.
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
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
Code: Select all
filter add chain=forward action=drop connection-state=new in-interface-list=IOT out-interface-list=LAN
filter add chain=forward action=drop connection-state=new in-interface-list=LAN out-interface-list=IOT
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.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
Sumptin like dis.......
As for the forward chain firewall filter rules............
...
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.
Code: Select all
/interface ethernet
set [ find default-name=ether1 ] name=ISP_eth1
set [ find default-name=ether2 ] name=Group1_eth2
set [ find default-name=ether3 ] name=Group1_eth3
set [ find default-name=ether4 ] name=Group2_eth4
set [ find default-name=ether5 ] name=Group2-eth5
/interface bridge
add name=GroupOne
add name=GroupTwo
/interface bridge port
add bridge=GroupOne interface=Group1_eth2
add bridge=GroupOne interface=Group1_eth3
add bridge=GroupTwo interface=Group2_eth4
add bridge=GroupTwo interface=Group2_eth5
/ip dhcp-server
add address-pool=dhcp-GP1 interface=GroupOne name=GP1LAN
add address-pool=dhcp-GP2 interface=GroupTwo name=GP2LAN
/ip address
add address=192.168.17.1/24 interface=GroupOne network=\
192.168.17.0
add address=192.168.18.1/24 interface=GroupTwo network=\
192.168.18.0
/ip dhcp-server network
add address=192.168.17.0/24 dns-server=192.168.17.1 gateway=192.168.17.1
add address=192.168.18.0/24 dns-server=192.168.18.1 gateway=192.168.18.1
/ip pool
add name=dhcp-GP1 ranges=192.168.17.10-192.168.17.50
add name=dhcp-GP2 ranges=192.168.18.5-192.168.18.100
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=FirstGroup
add name=SecondGroup
/interface list member
add comment=defconf interface=ISP_eth1=WAN
add interface=Group1_eth2 list=LAN
add interface=Group1_eth3 list=LAN
add interface=Group1_eth4 list=LAN
add interface=Group1_eth5 list=LAN
add interface=GroupOne list=FirstGroup
add interface=GroupTwo list=SecondGroupCode: Select all
/ip firewall filter
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalidWhich 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'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
anav, my friend, I was trying to teach OP to catch a fish ... not to go to a supermarket to buy pre-fried fish sticks.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
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)
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)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
Superwhat? It must be some Yankee stuff again, I'm surprised you Canadiens fall for it so often. ;-)
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
Thanks for both responses- appreciate it very much. I'm going fishing now... :-)
Re: Splitting Ports into Seperate Isolated Networks
Think of it as the Rugby World Championships but with padding!Superwhat? It must be some Yankee stuff again, I'm surprised you Canadiens fall for it so often. ;-)
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
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
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
Code: Select all
filter add chain=forward action=drop connection-state=new in-interface-list=IOT out-interface-list=LAN
filter add chain=forward action=drop connection-state=new in-interface-list=LAN out-interface-list=IOT
Thank you.
Re: Splitting Ports into Seperate Isolated Networks
Not rules I suggested LOL, perhaps the one who gave you those rules,that leak like a sieve, can help you! ;-).
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
Not rules I suggested LOL, perhaps the one who gave you those rules,that leak like a sieve, can help you! ;-).
LOL. You guys are so funny! I'll take a closer look at the rules you posted. :-)
Re: Splitting Ports into Seperate Isolated Networks
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:I ... ter#ChainsWith 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?
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.
Re: Splitting Ports into Seperate Isolated Networks
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"
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!
Code: Select all
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
Re: Splitting Ports into Seperate Isolated Networks
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.
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.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
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).
Good to know (layer of MT and networking knowledge depth I will never have).
Code: Select all
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="Allow ADMIN to Router" log-prefix=\
AdminAccess src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow NTP service" connection-state=\
new dst-port=123 in-interface-list=LAN protocol=udp src-address-list=\
NTPserver
add action=drop chain=input comment="Drop All Else"I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
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?
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?
Re: Splitting Ports into Seperate Isolated Networks
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.
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.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
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.
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.
Re: Splitting Ports into Seperate Isolated Networks
Yes.Is that correct?
I concur that ROS learning curve is steep indeed. It helps if newbie has good knowledge of how linux kernel works but that's not common at all.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
Thus MKX the question in my mind remains,
a. having a drop all else rule in the input chain, will prevent.
b. computer on subnet A, being able to ping gateway of subnet B.
????????
a. having a drop all else rule in the input chain, will prevent.
b. computer on subnet A, being able to ping gateway of subnet B.
????????
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
MTUNA Certified, by the Ascerbic Llama!
MTUNA Certified, by the Ascerbic Llama!
Re: Splitting Ports into Seperate Isolated Networks
As I explained: connections (including pings) from any client (any of subnets, internet included) to any of router's IP addresses is handled by chain=input. So if you have as last rule in input chain one dropping everything, and none of preceeding rules allow that particular connection, then pinging "non-native" router's address won't work. But if there aren't any specislly crafted allow rules fir pinging "native" router0s address, then no ping will work.
Let's say router has two LAN IP addresses: 192.168.88.1/24 and 192.168.42.1/24. With usual firewall rules, client with address 192.168.42.42 will be able to ping router at 192.168.88.1. If you want to allow connections (including pinging) only to "native" IP address (and use the ultimate drop all rule you're so fond of), you'd have to use something like this (didn't actually try it):
But such construct doesn't really add any security to the setup, it's only esthetical issue.
Let's say router has two LAN IP addresses: 192.168.88.1/24 and 192.168.42.1/24. With usual firewall rules, client with address 192.168.42.42 will be able to ping router at 192.168.88.1. If you want to allow connections (including pinging) only to "native" IP address (and use the ultimate drop all rule you're so fond of), you'd have to use something like this (didn't actually try it):
Code: Select all
/ip firewall filter
...
add chain=input action=allow dst-address=192.168.88.1 src-address=192.168.88.0/24
add chain=input action=allow dst-address=192.168.42.1 src-address=192.168.42.0/24
add chain=input action=drop
But such construct doesn't really add any security to the setup, it's only esthetical issue.
BR,
Metod
Metod
Re: Splitting Ports into Seperate Isolated Networks
I'm very appreciative for all of the help with this. I've got the router up and running and have learned a lot this past week thanks to you guys. I am feeling a small bit more comfortable with ROS and it's staring to get a bit fun. :-) After setting things up and playing with this a bit I thought of a slight twist to the scenario and was wondering if this scenario was possible with firewall rules. It's basically a one way block of traffic. The scenario is like this...
Network LAN (192.168.81.1) on port ether1/2 is the trusted network.
Network IOT (192.168.89.1) on port ether3/4 is the untrusted network.
Requirement 1: There is a media server on the IOT network which I don't want to have access to LAN (ie, it can't initiate traffic sent to the LAN).
Requirement 2: Computers on the LAN network want to stream medai that is on the media server on the IOT network.
Requirement 3: LAN can have unlimited access to the IOT network
Firewall Behavior:
1. Blocks all traffic that originates from the IOT network that is destined to the LAN network.
2. Allow traffic from the IOT network that is destined to the LAN netork only if that traffic is a response to a request that originalted from the LAN network.
3. Allow all traffic that originates from the LAN network that is destined to the IOT network.
Is it as simple as this? I'm not certain if with this rule the media server on the IOT network would be able to respond to requests from the comuters on the LAN?
Thank you.
Network LAN (192.168.81.1) on port ether1/2 is the trusted network.
Network IOT (192.168.89.1) on port ether3/4 is the untrusted network.
Requirement 1: There is a media server on the IOT network which I don't want to have access to LAN (ie, it can't initiate traffic sent to the LAN).
Requirement 2: Computers on the LAN network want to stream medai that is on the media server on the IOT network.
Requirement 3: LAN can have unlimited access to the IOT network
Firewall Behavior:
1. Blocks all traffic that originates from the IOT network that is destined to the LAN network.
2. Allow traffic from the IOT network that is destined to the LAN netork only if that traffic is a response to a request that originalted from the LAN network.
3. Allow all traffic that originates from the LAN network that is destined to the IOT network.
Is it as simple as this? I'm not certain if with this rule the media server on the IOT network would be able to respond to requests from the comuters on the LAN?
Code: Select all
filter add chain=forward action=drop connection-state=new in-interface-list=IOT out-interface-list=LAN
Thank you.
Re: Splitting Ports into Seperate Isolated Networks
If you have the default 'allow forward established/related/untracked connection' rule before your rule, yes. The first request from PC on LAN network to media server on IOT network has the connection state new, the reply from media server to PC has the state established and hits this rule.
If you also have the default 'drop forward invalid' rule there is no need to explicitly check connection-state=new in subsequent rules as this is the only state left, and saves a small amount of CPU processing.
Whilst segregating networks is good, using a layered approach to security, a whole other can of worms which can arise - a lot of home / SOHO devices use broadcast or multicast discovery mechanisms (mDNS, DLNA, etc.) and this does not propagate beyond each network
If you also have the default 'drop forward invalid' rule there is no need to explicitly check connection-state=new in subsequent rules as this is the only state left, and saves a small amount of CPU processing.
Whilst segregating networks is good, using a layered approach to security, a whole other can of worms which can arise - a lot of home / SOHO devices use broadcast or multicast discovery mechanisms (mDNS, DLNA, etc.) and this does not propagate beyond each network
Re: Splitting Ports into Seperate Isolated Networks
To MKX and others,
I tested on my rb750 using the default firewall in order to test blocking the pings from vlanA/subnetA to the gateway of vlan/subnetB which we have been talking about. I found that I had to install tdw/mkx's drop chain=input rule ahead of the default "allow chain=input icmp". It seems like ping must be using icmp? The allow icmp is pretty earlier in the default firewall, so the new drop input rule for blocking ping has to go even higher. After messing about with this I am in camp with MKX and TDW... blocking this ping to internal router interfaces is probably not worth the clutter it causes in the firewall rules.
But with regard to anav question about his drop-all methods at the tail end of the input chain, I don't think his drop-all would actually block these pings because I suspect he too has the icmp allowed early in the list of input rules.
Or did I make a mistake and need to do more reading?
I tested on my rb750 using the default firewall in order to test blocking the pings from vlanA/subnetA to the gateway of vlan/subnetB which we have been talking about. I found that I had to install tdw/mkx's drop chain=input rule ahead of the default "allow chain=input icmp". It seems like ping must be using icmp? The allow icmp is pretty earlier in the default firewall, so the new drop input rule for blocking ping has to go even higher. After messing about with this I am in camp with MKX and TDW... blocking this ping to internal router interfaces is probably not worth the clutter it causes in the firewall rules.
But with regard to anav question about his drop-all methods at the tail end of the input chain, I don't think his drop-all would actually block these pings because I suspect he too has the icmp allowed early in the list of input rules.
Or did I make a mistake and need to do more reading?
Last edited by simpleIT on Sun Feb 14, 2021 4:01 am, edited 1 time in total.
Re: Splitting Ports into Seperate Isolated Networks
Oh no... that sound a huge storm cloud looming in my future. I hadn't really given much thought about how complicated it might become to get device interoperability back for certain devices once all this vlan/network segregation is done. Might have to think about mapping out this a bit more.Whilst segregating networks is good, using a layered approach to security, a whole other can of worms which can arise - a lot of home / SOHO devices use broadcast or multicast discovery mechanisms (mDNS, DLNA, etc.) and this does not propagate beyond each network
Who is online
Users browsing this forum: Google [Bot] and 77 guests