Starting with the CCR1009, the main change is not to mix vlans and not vlans.
Best/simple/clear to use all vlans… (by that I mean not vlan1 for anything other than default bridge settings).
So Convert/Create…
Create vlan11 with Ip address 192.168.48.0/24, as well as IP pool, Dhcp server, DHCP Server network.
This appears to be your management VLAN!!
All smart devices should have an IP address from this subnet!!
I see that VLAN104 is also going to the switch.
Conclusion: You only have two subnets going to the CR switch. Then why do you need to connect them to the UNIFI switch?
If there is no vlan104 on the unifi switch (no possible direct traffic switch to switch) then what is the point? Any vlan X, to vlanY traffic will have to go through the router anyway?
In general, all the vlan interfaces should be created with interface being the ONE bridge port, with appropriate /interface bridge port settings and appropriate /interface bridge vlan settings.
(I see sfp+8 is not even on the bridge port settings)
Unless this actually serves some purpose would set all to NONE!
/interface detect-internet
set detect-interface-list=Native-WAN internet-interface-list=WAN-All
lan-interface-list=LAN wan-interface-list=WAN-All
Dislike your interface list naming convention, NOT clear and is confusing.
Stick to norms.
/interface list
add name=WAN-All
add name=LAN
add name=Native-WAN
Try
WAN (for WAN connections)
LAN (for all vlans)
control (for management vlan)
Internet (for vlans allowed internet access) (not required if ALL VLANS are allowed internet)
Rule of thumb: if you have two or more subnets (but not all of them) that are allowed or should have access to something create an interface list!!
For example these are all better setup as 4 interface lists (vice source-address lists).
SENSITIVE
IOT-WL
CLIENT-LAN
EXTERNAL-CLIENT
Final comment on the topic, firewall address lists are best used when you have a subset of IPs from a subnet involved, any mix of IPs across subnets, or any mix of IPs and whole subnets.
In terms of interface list members.
for LAN, ensure you name all vlans (bridge not required).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
FIREWALL Rules
INPUT CHAIN
These are kind of not all that useful. Remember the rule above already blocked all WAN traffic (not dst-natted).
add action=drop chain=input comment=“Block Winbox connections on WAN”
dst-port=8291 in-interface=ether8-gateway protocol=tcp
add action=drop chain=input comment=
“Block Mikrotik Bandwidth Test connections on WAN” dst-port=2000
in-interface=ether8-gateway protocol=tcp
add action=drop chain=input comment=“Drop inbound TCP DNS” dst-port=53
in-interface=ether8-gateway protocol=tcp
add action=drop chain=input comment=“Drop inbound UDP DNS” disabled=yes
dst-port=53 in-interface=ether8-gateway protocol=udp
add action=drop chain=input comment=
“Drop all packets which does not have unicast source IP address”
src-address-type=!unicast
add action=drop chain=input comment=“Drop all packets from public internet whi
ch should not exist in public network” in-interface-list=WAN-All
src-address-list=NotPublic
In any case, they can all be replaced by three simple rules.
1 - only allow admin to router FROM the LAN (no LAN users require full access to the router only the admin)
2- allow required services traffic from LAN users to the router (DNS.NTP etc.)
3. block all else
(1) Looks like
add action=accept chain=input in-interface-list=Control (or in-interface=vlan11) {optional: src-address-list=adminaccess}
where firewall address list “adminaccess” is comprised of static dhp leases
add address=IP of admin desktop list=adminaccess
add address=IP of admin laptop list=adminaccess
add address=IP of admin smartphone list=adminaccess
etc…
(2) allow DNS queries (if the router provides ntp that as well should be added here udp port 123l)
add action=accept chain=input comment=“Allow LAN DNS queries-UDP”
connection-state=new dst-port=53,123 in-interface-list=LAN protocol=udp
add action=accept chain=input comment=“Allow LAN DNS queries - TCP”
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
(3) add action=drop chain=input comment=“drop all else”
FORWARD CHAIN
Stick to the defaults as provided, getting too fancy is best left to the necessary admin entered rules where you delineate what traffic is ALLOWED.
Just like the input chain, we use a drop everything else rule at the end very much simplifying your rules!!
So recommend
add action=accept chain=forward comment=“defconf: accept in ipsec policy” \ (if not doing ipsec these 2 rules can be disabled/removed)
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=invalid log=yes log-prefix=invalid
add action=drop chain=forward comment=“drop all else”
*********** This is where you need to put what traffic IS ALLOWED ***********************
Typically allow LAN to WAN for internet
Typically allow a shared device across vlans (like a printer)
Typically allow admin access to all Vlans
Typically allow dst-nat (if doing any port forwarding)
Now I see you have some specific concerns that touch upon
a. bad traffic leaving the LAN Towards the internet
c. One IP on one vlan (dmz) has a specific requirement
SO you have to decide what you need to block before the following more general allow rule for LAN to Internet traffic!!!
Note that by default ALL vlan to vlan traffic is already blocked, so do not have to worry about that
Note that by default all LAN to WAN traffic is blocked
Note by default all WAN to LAN traffic is blocked.
For example these rules… What are you actually trying to achieve??
- add action=drop chain=forward log-prefix=DMZ protocol=tcp src-address=
192.168.122.90 src-port=!443
It seems this is an internet access attempt to block all http traffic to the internet (but you are missing out-interface-list=WAN and protocol tcp )
Since the rest of the DMZ it appears needs full access to the internet, we need to match a rule for this particular Device JUST BEFORE the ALLOW RULE for lan to wan traffic.
add action=drop chain=forward in-interface=vlanDMZ source-address=192.168.122.90 dst-port=!443 protocol=tcp out-interface-list=WAN
That is the simple and most direct way.
The other is to create an Internet Interface list that the DMZ does not belong too. So the general rule does not apply to the DMZ.
Then create two rules and order in relation to the general rule does not matter.
add chain=forward action=accept in-interface=vlandmz source-address=**!**192.168.122.90 out-interface-list=WAN ( allow all traffic from rest of DMZ)
add chain=forward action=accept in-interface=vlandmz source-address=192.168.122.90 dst-port=443 out-interface-list=WAN (allow only HTTPS traffic from specific dmz IP)
2. add action=drop chain=forward comment=“Drop all packets from public internet w
hich should not exist in public network” in-interface-list=WAN-All
src-address-list=NotPublic
This looks to ensure, that no internet traffic that is not public should enter the router?
NOT REQUIRED: All WAN to LAN traffic is blocked by default!!
-
add action=drop chain=forward comment=“Drop all packets in local network which
_does not have local network address” in-interface-list=LAN src-address=
!192.168.0.0/16
NOT REQUIRED: All vlan to vlan traffic is blocked by default.
-
add action=drop chain=forward comment=“Drop all packets from local network to
internet which should not exist in public network” disabled=yes
dst-address-list=NotPublic in-interface-list=LAN out-interface-list=WAN
This rule wants to ensure that no bad internet (dst) addressess are sent out from the router.
Not a bad rule but need to add out interface.
Better (courtesy of sindy) is to create black hole routes for such addresses.
-
add action=drop chain=forward comment=
“Block IOT Traffic to critical LAN Segments” connection-state=
invalid,new,untracked dst-address-list=Sensitive-Internal in-interface=
iot-net log=yes log-prefix=iot-drop src-mac-address=!90:DD:5D:CA:59:A7
add action=accept chain=forward comment=
NOT REQUIRED, all vlan to vlan traffic is blocked by default.
Last comment. clean up these settings for security
_/ip service
set telnet disabled=yes
set ftp disabled=yes
set www address=192.168.0.0/16
set ssh address=192.168.0.0/16
set api address=192.168.0.0/16
set winbox address=192.168.0.0/16
set api-ssl address=192.168.0.0/_16
Only enabled ones should be winbox and perhaps SSH, unless you have specific reasons/needsd.
certainly WWW is a bad idea and API.
The winbox should be matched to your control subnet!
