I went through the forum and set up my router based on what I have read. I would however be very grateful if any forum guru could verify whehther I got it right. I am particularly concerned whether:
My Wifi Setup is correctly configured and safe
My IPv4 rules are correctly cofigured and my IPv6 settings correctly disabled, so my router is safe to use
My entire config is as follows (any help would be greatly appreciated):
# 2024-11-19 16:30:13 by RouterOS 7.15.3
# software id = KSYB-YVIV
#
# model = C53UiG+5HPaxD2HPaxD
/interface bridge
add name=Bridge-LAN
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether2 ] disabled=yes name=ether2-LAN
set [ find default-name=ether3 ] disabled=yes name=ether3-LAN
set [ find default-name=ether4 ] disabled=yes name=ether4-LAN
set [ find default-name=ether5 ] disabled=yes name=ether5-LAN
/interface list
add name=WAN
add name=LAN
/interface wifi configuration
add channel.band=2ghz-ax .width=20/40mhz-eC country=Germany disabled=no \
mode=ap name="2.4ghz Config" security.authentication-types=wpa3-psk .wps=\
disable ssid=TestNet
add channel.band=5ghz-ax .width=20/40mhz-eC country=Germany disabled=no \
mode=ap name="5ghz Config" security.authentication-types=wpa3-psk .wps=\
disable ssid=TestNet5G
/interface wifi
set [ find default-name=wifi1 ] configuration="5ghz Config" \
configuration.mode=ap name=Wifi1-5ghz security.authentication-types=\
wpa3-psk .wps=disable
set [ find default-name=wifi2 ] configuration="2.4ghz Config" \
configuration.mode=ap disabled=no name=Wifi2-2.4ghz \
security.authentication-types=wpa3-psk
/ip pool
add name=dhcp_pool1 ranges=192.168.0.20-192.168.0.254
/ip dhcp-server
add address-pool=dhcp_pool1 interface=Bridge-LAN name=dhcp1
/interface bridge port
add bridge=Bridge-LAN interface=ether2-LAN
add bridge=Bridge-LAN interface=ether3-LAN
add bridge=Bridge-LAN interface=ether4-LAN
add bridge=Bridge-LAN interface=ether5-LAN
add bridge=Bridge-LAN interface=Wifi2-2.4ghz
/ip neighbor discovery-settings
set discover-interface-list=none
/ip settings
set rp-filter=strict tcp-syncookies=yes
/ipv6 settings
set accept-redirects=no accept-router-advertisements=no disable-ipv6=yes \
forward=no
/interface list member
add interface=ether1-WAN list=WAN
add interface=Bridge-LAN list=LAN
/ip address
add address=192.168.0.1/24 interface=Bridge-LAN network=192.168.0.0
/ip cloud
set update-time=no
/ip dhcp-client
add interface=ether1-WAN
/ip dhcp-server lease
add address=192.168.0.15 client-id=1:XX:XX:XX:XX:XX:XX comment=XAdmin \
mac-address=XX:XX:XX:XX:XX:XX server=dhcp1
/ip dhcp-server network
add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1
/ip dns
set allow-remote-requests=yes
/ip firewall address-list
add address=192.168.0.15 comment=XAdmin list=Authorized
/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" \
connection-state=established,related,untracked
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=accept chain=input comment="admin access" src-address-list=\
Authorized
add action=accept chain=input comment="users to services" dst-port=53 \
in-interface-list=LAN protocol=udp
add action=accept chain=input comment="users to services" dst-port=53 \
in-interface-list=LAN protocol=tcp
add action=drop chain=input comment="drop all else"
add action=accept chain=forward comment=\
"accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid
add action=accept chain=forward comment="internet traffic" in-interface-list=\
LAN out-interface-list=WAN
add action=drop chain=forward comment="drop all else"
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-WAN
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes port=2421
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
/ipv6 firewall filter
add action=drop chain=input comment="Drop all IPv6 ICMP traffic" protocol=\
icmpv6
add action=drop chain=input comment="Drop all other IPv6 traffic"
add action=drop chain=forward comment="Drop all IPv6 forward traffic"
add action=drop chain=output comment="Drop all IPv6 output traffic"
/ipv6 nd
set [ find default=yes ] disabled=yes
/system clock
set time-zone-name=Europe/Brussels
/system note
set show-at-login=no
/system ntp client
set enabled=yes
/system ntp client servers
add address=0.pool.ntp.org
add address=1.pool.ntp.org
add address=2.pool.ntp.org
add address=3.pool.ntp.org
/tool bandwidth-server
set enabled=no
/tool mac-server
set allowed-interface-list=none
/tool mac-server mac-winbox
set allowed-interface-list=none
/tool mac-server ping
set enabled=no
It should be pushed to the top of rules for forward chain, above existing āaccept established,related,untrackedā rule.
2. Iād allow some means of management other than winbox over IP. It might come handy if your only allowed management becomes unavailable for some reason. Personally Iām fan of winbox MAC access for ultimate backup access, but I donāt know if thatās feasible ā¦ youāre limiting management access to certain IP address. Which, BTW, is not very safe as IP address can be set manually bypassing DHCP serverās static lease.
You forgot to include your 5ghz wifi WLAN in /interface bridge port settings /interface bridge port
add bridge=Bridge-LAN interface=ether2-LAN
add bridge=Bridge-LAN interface=ether3-LAN
add bridge=Bridge-LAN interface=ether4-LAN
add bridge=Bridge-LAN interface=ether5-LAN
add bridge=Bridge-LAN interface=Wifi2-2.4ghz add bridge=Bridge-LAN interface=Wifi1-5ghz
Use neighbours discovery set to LAN ( works with winbox and max and 7. to make your router config access easy )
/ip neighbor discovery-settings
set discover-interface-list=LAN
Use RP filter loose, not strict and forget about tcp syncookies /ip settings
set rp-filter=loose tcp-syncookies=no
I would add a dynamic dns server if not using the ISP one /ip dns
set allow-remote-requests=yes server=1.1.1.1
FIREWALL RULES look familiar and are fine except as MKX pointed out missing fasttrack /ip firewall filter
add action=accept chain=input comment=āaccept established,related,untrackedā
connection-state=established,related,untracked
add action=drop chain=input comment=ādrop invalidā connection-state=invalid
add action=accept chain=input comment=āaccept ICMPā protocol=icmp
add action=accept chain=input comment=āadmin accessā src-address-list=
Authorized
add action=accept chain=input comment=āusers to servicesā dst-port=53
in-interface-list=LAN protocol=udp
add action=accept chain=input comment=āusers to servicesā dst-port=53
in-interface-list=LAN protocol=tcp
add action=drop chain=input comment=ādrop all elseā
++++++++++++ add action=fasttrack chain=forward connection-state=established,related add action=accept chain=forward comment=
āaccept established,related,untrackedā connection-state=
established,related,untracked
add action=drop chain=forward comment=ādrop invalidā connection-state=invalid
add action=accept chain=forward comment=āinternet trafficā in-interface-list=
LAN out-interface-list=WAN
add action=drop chain=forward comment=ādrop all elseā
All you need to do for ipv6 if not using is to not use ipv6 services as you have done but only need two simple rules add chain=input action=drop
add chain=forward action=drop
Set to LAN, this facilitates encrypted winbox access when on the router.
/tool mac-server mac-winbox
set allowed-interface-list=LAN
Your address list is lackingā¦ You should be using static DHCP leases! /ip firewall address-list
add address=192.168.0.15 comment=āadmin local desktop wiredā list=Authorized
add address=192.168.0.X comment=āadmin laptop wifiā list=Authorized
add address=192.168.0.Y comment=" admin smartphone/ipad" list=Authorized
Anav & mkx, I actually have three small follow-up questions regarding the above in case you have another moment. I changed my setup above slightly so that I can separate my work traffic from my home traffic and therefore created two simple VLANs (Home-VLAN / ID 10 which includes both 2.4 & 5ghz wifi-networks as well as all LAN ports; and a Work-VLAN / ID 20 which only includes a separate 2.4ghz wifi-network - consider it as a Guest wifi-network). I heavily relied on the following VLAN guide which is very useful (Router-Switch-AP (all in one) - http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1) with some minor adjustments such as access rights based on AnavĀ“s āauthorized listā in the firewall settings (/ip firewall address-list) instead of, as advised in the guide, setting up a third VLAN as a management VLAN with the ID 99.
Do the firewall rules you checked above still provide the same security in VLAN setup or am I missing something and they should be adjusted somehow? I only changed LAN to VLAN in the following rules:
add action=accept chain=input comment=āusers to servicesā dst-port=53 \ in-interface-list=VLAN protocol=udp
add action=accept chain=input comment=āusers to servicesā dst-port=53 \ in-interface-list=VLAN protocol=tcp
Are my firewall rules and settings correctly applied so that devices on VLAN 10 (Home network) are properly separated and cannot communicate with devices on VLAN 20 (Work network) and vice versa?
The VLAN guide I referred to uses protocol mode none (/interface bridge add name=BR1 protocol-mode=none vlan-filtering=no). I have currently the default RSTP selected. My setup works without any issues. Does this still need to be changed (e.g. to MSTP or none) and if so, what would be the advantages of a change?
My routing table is as follows:
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAd 0.0.0.0/0 192.168.0.1 1
DAc 192.168.10.0/24 VLAN-Home 0
DAc 192.168.20.0/24 VLAN-Work 0
DAc 192.168.0.0/24 ether1-WAN 0
Despite the fact that you quote yourself to add a oneliner comment could you be so kind and edit your posts to use proper code tags? It would help a lot.
Should be good as is, will take a quick peek. Yup all secure!
Not wrong but I prefer to be clear about all settings /interface bridge vlan
add bridge=Bridge-LAN tagged=Bridge-LAN untagged=ether2-LAN,ether3-LAN,ether4-LAN,ether5-LAN,Wifi1-5ghz,Wifi2-2.4ghz vlan-ids=10
add bridge=Bridge-LAN tagged=Bridge-LAN untagged=wifi2-2.4ghz-Work vlan-ids=20
2.I would recommend adding all applicable admin device IPs to the authorized list.
aka, what about any smartphone/ipad, laptop using wifiā¦
Set this to none only the āmac-server mac-winboxā being encrypted should be accessible.
/tool mac-server
set allowed-interface-list=VLAN-Admin
/tool mac-server mac-winbox
set allowed-interface-list=VLAN-Admin
Thanks for the code tag advice, I was not aware of this feature. Changed it.
As for quoting myself, I do not see the issue with that. Better be too precise and make clear references than create misunderstandings and waste everyoneās time unnecessarily.
Please use [ code ] tag under </> button in the editor instead of quote one.
If you use forum theme like āsilverā one then your posts are more than half a meter/several screens long . Code tags do the job for every theme.
You can always do cut out most of the quote and leave the crucial part if you want to refer it
@anav I have some general questions regarding your RP filter suggestion:
According to https://wiki.mikrotik.com/Manual:IP/Settings the settings for the RP filter are ārp-filter (loose | no | strict; Default: no)ā. Why do you suggest to have it set to loose instead of strict and even more surprising, why is the default MikroTik setting ānoā?
Is this not supposed to be a security feature which would be beneficial to have set to strict or are there no benefits in doing so? The MikroTik wiki also states āCurrent recommended practice in RFC3704 is to enable strict mode to prevent IP spoofing from DDoS attacks.ā
For most of the setup configurations where a default route (destination 0.0.0.0/0 or ::/0) exists in the main table, there would be no different between rp-filter=no and rp-filter=loose, because as long as that route is in the active state, the loose reverse path check will always succeed, regardless of the source IP address. So rp-filter=no will have the same effect and consumes less processing resources.
And in the docs you can see that having rp-filter=strict is not compatible routing tables. The check only works with the main routing table (no multi-WAN load balancing with PCC for example), and if I have to guess, would probably not work in case of ECMP routes.
@CGGXANNX Very interesting and detailed answer, in this case I have a question as well: My config was recently changed since starting this thread: With the help of @anav and others, I added one VLAN which connects via wireguard to a VPN provider (all other VLANS still connect directly to my ISP). Hence routing tables were needed which are incompatible with rp-filter=strict. The entire config and information could be found here: One VLAN/SSID over Wireguard - #20 by whuupwhuup
Is it possible to:
Receive the same security rp-filter=strict would achieve by having the rp-filter set to ānoā or ālooseā and instead tweaking a different ROS setting (e.g. harden a firewall rule)?
Achieve the same setup I currently have (all VLANS via ISP, except one via wireguard to a VPN provider) without using routing tables so rp-filter=strict can be enabled?
Apply rp-filter=strict solely on an interface basis instead of for the entire router and thus solely have it set to ānoā or ālooseā for the wireguard VPN VLAN?
Setting rp_filter per network interface is possible in Linux but currently MikroTik does not make such setting available in RouterOS, so maybe you can send a feature request as support ticket to MikroTik?
I donāt think #2 is possible, but maybe others in this thread know more and can suggest something?
To be honest, looking at your current configuration, I donāt really see a need for rp-filter=strict. Your current firewall filters drop or accept mostly based on incoming interface, not source address. Letās look at the potential threats that normally can be addressed by rp-filter=strict:
Some bad guy from the internet might send packets with spoofed source addresses (belonging to your LAN IP ranges) to your router ā this is already blocked, except for ICMP.
Some rogue devices in your VLANs might try to send packets to the other VLANs and faking the source address ā this is not possible because your current firewall drops inter-VLAN traffics.
Some rogue devices in your VLANs might try to send packets to the router, with source address belonging to the subnets of other VLANs, so that the router sends the responses to the devices in the other VLANs ā this currently only applies to DNS 53. Please note that even if the devices were in the VLAN-Admin interface list, which currently only includes the VLAN-Home interface, faking src-address to something of other subnet will only allow access to DNS 53 ports, not the other ports, because that admin rule also checks for src-address-list=Authorized. The fake source address would not belong in that address list!
Some rogue devices in your VLANs might try to send packets to the internet (WAN), with fake src-address belonging to the other VLAN subnets. In this case, when the host from the internet responds, the packets might be redirected to devices in the other VLANs. However, most of the recipients will probably rejects those unexpected incoming packets with source address belonging to the internet.
Some rogue devices in your VLANs might try to send packets to the internet (WAN), with fake src-address belonging to non-private address ranges on the Internet. In this case, your router will masquerade the source address to its own WAN IP address before sending the packet to the internet. When the remote host responds, the router will receive the response packets, un-NATs it and will try to send that packet to the fake address on the internet. This case will be a forwarding from in-interface-list=WAN to out-interface-list=WAN, so maybe you can add these rules to the TOP of the forward chain (before the fasttrack rule) to drop it:
@CGGXANNX Thank you so much for all these insights! Once again super helpful!
Just a small follow-up question: Is there any benefit in replicating rp-filter=strict via RAW rules as opposed to options 1 or 2 you mentioned or is the result the same if I tweak the existing firewall rules (e.g. option 2)?
Just chiming in to say that @CGGXANNXās point is totally correct and source addresses really should always be validated in some way. Until we have per-interface rp-filtering, the firewall is the best place to do it.
Actually, I use a 3rd (or 5th, whatever) option. I put the ādrop in-interface src-address=!..ā rules not in the raw/prerouting chain, but into a separate chain, which is jumped to from both the filter/input and filer/forward chains. This jump happens after the usual (fasttrack)->established->invalid rule dual or triplet.
This results in (slightly) better performance, because if fasttrack is not used, the raw rules are executed for each packet before the established/related rule and so potentially many more rules have to be evaluated. If they are after the established/related rule than they are only evaluated for new connections, like the rest of the filter rules. Itās safe to assume that incorrect source addresses are relatively rare.
Another very minor comment would be that packets sourced from wireguard tunnels donāt have to be validated, because they are already validated according to allowed ips in the wireguard implementation itself. Again, itās very minor, and if itās better for muscle memory to do this for every interface, then itās all good.
Better discussed as an overall firewall rule approach, beyond the standard setup as opposed to getting mired down into ip filter strict loose debatesā¦ Keep it loose allows most flexiblity and future proofing and does not pose a security issue. If you want additional security steps, then simply apply more firewall rules ( including raw ) but for most folks not really needed.
. Code tags do the job for every theme.