[MikroTik-apparatuur] Ervaringen &amp; Discussie

vrijdag 10 april 2026 10:14

dubbel

[ Voor 99% gewijzigd door Mit-46 op 10-04-2026 10:14 ]

Acties:

vrijdag 10 april 2026 10:16

ed1703 schreef op vrijdag 10 april 2026 @ 09:52:
[...]

Nope, Voor Mikrotik dien je eerst een basis firewall in te richten..

code:

/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=drop chain=input comment="drop all not coming from LAN" in-interface-list=!LAN
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="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="accept out ipsec policy" ipsec-policy=out,ipsec
add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat in-interface-list=WAN

Nieuwe accept regels from WAN (bijvoorbeeld Wireguard) zet je dan voor de "drop all not coming from LAN"

Een nieuw VLAN voeg je eventueel (hangt er een beetje vanaf wat de bedoeling is van dat VLAN) toe aan je interface list LAN.

Dank!
Ik ga ze straks een naast elkaar leggen.

Ik probeer mijn config te printen, maar deze stopt (of blijft hangen) bij rule 6 terwijl het er 13 zijn. Misschien even geduld hebben.

Acties:

vrijdag 10 april 2026 13:43

Thralas schreef op vrijdag 10 april 2026 @ 10:05:
[...]

Ja, dat moet je absoluut doen.

De default config heeft een firewall die veilig is. Een lege config komt ook zonder firewall en dat is (zoals je hebt gemerkt) echt niet veilig. Voeg aan de default config alleen regels toe die je begrijpt.

Om nog maar eens driedubbel te benadrukken: je wil de managementinterfaces nooit openstellen voor het internet. Als ze het wachtwoord niet raden dan is je router na een paar maanden alsnog gehackt zodra er weer eens een kwetsbaarheid in de managementinterface blijkt te zitten. Er is precent genoeg.

Het alternatief heb je gelukkig al ontdekt: Back To Home zet een VPN op: dat is een uitstekende manier om er wél bij te kunnen vanaf het internet.

Check!
Ga ik dat zo meteen maar doen.

Dank voor de input!

Acties:

pimlie

@BaseBoyNL RouterOS ondersteunt een soort van fail2ban m.b.v. dynamic address lists & timeouts.

Hier hoe je dat toepast (uit de oude mikrotik docs, kan ik zo snel even geen link voor vinden). Ik heb een chain genaamd svcp-SSH dat automatisch ip addressen blokkeert als ze meer dan 3x in ca 3 minuten verbinding proberen te maken. Die 3x kan je aanpassen door meer of minder 'kleuren' te gebruiken'.

Het idee is dus dat:
- iemand verbind met SSH -> ip toegevoegd aan light gray adres lijst voor 1 min
- iemand verbind weer met SSH en zijn ip is in light gray -> gray voor 1 min
- iemand verbind weer met SSH en zijn ip is in gray -> dark gray voor 1 min
- iemand verbind weer met SSH en zijn ip is in dark gray -> geblocked voor 2 weken

Als er ip adressen zijn die je vertrouwt, voeg die dan toe aan de my-TRUSTED-IPs adres lijst zodat die nooit aan light gray worden toegevoegd. Anders blokkeer je je zelf ook als je 3x (succesvol) binnen 3 min inlogt.

code:

add action=return chain=svcp-SSH dst-port=!22 protocol=tcp
add action=return chain=svcp-SSH protocol=!tcp
add action=add-src-to-address-list address-list=SSH-BLACKLIST address-list-timeout=2w chain=svcp-SSH src-address-list=SSH-DARKGRAY
add action=drop chain=svcp-SSH src-address-list=SSH-BLACKLIST
add action=add-src-to-address-list address-list=SSH-DARKGRAY address-list-timeout=1m chain=svcp-SSH src-address-list=SSH-GRAY
add action=add-src-to-address-list address-list=SSH-GRAY address-list-timeout=1m chain=svcp-SSH src-address-list=SSH-LIGHTGRAY
add action=add-src-to-address-list address-list=SSH-LIGHTGRAY address-list-timeout=1m chain=svcp-SSH src-address-list=!my-TRUSTED-IPs
add action=accept chain=svcp-SSH

Je hoeft uiteraard niet een aparte chain te gebruiken, maar om mijn firewall overzichtelijk te houden definieer ik chain's per applicatie / port. Vervolgens kan je dan je binnenkomende verkeer via jump-targets door deze chain sturen:

code:

add action=jump chain=input in-interface-list=wans jump-target=in-WAN
add action=jump chain=in-WAN jump-target=svcp-SSH
... andere toegestane services
add action=drop chain=in-WAN

Let wel (1), je zou dit alleen moeten gebruiken voor services die je alleen voor jezelf daadwerkelijk publiekelijk toegankelijk wilt hebben. Het beste zou uiteraard zijn om enkel een adressen lijst als whitelist te gebruiken en/of om de ssh of telnet service niet op een standard port te draaien:

code:

1	add action=accept chain=svcp-SSH dst-port=22 protocol=tcp src-address-list=my-TRUSTED-IPs

Let wel (2), dat op mijn manier van het gebruiken van chains & jump-targets je significant meer firewall regels krijgt. Voor huis, tuin en keukengebruik zou dat niet een groot probleem moeten zijn, maar hoe meer firewall regels des te hogere latency uiteraard. Zelf vind ik een overzichtelijke firewall belangrijker.

zaterdag 11 april 2026 14:16

Acties:

zaterdag 11 april 2026 14:33

Je telnet poort hoef je zeker niet van buiten open te zetten.
Als je klaar bent met je firewall is het altijd een goed idee om een portscan op je eigen ip adres te doen van af buiten. bijv https://dnschecker.org/port-scanner.php

Wat fail2ban betreft je kunt wel iets dergelijks zelf maken.
https://help.mikrotik.com...176/Bruteforce+prevention

OF je kunt het met een omweg doen door je logs weg te schrijven naar een rsyslog server en daar fail2ban op draaien die een adres lijst met block regel manipuleert op je mikrotik.

Acties:

chaoscontrol

Ik zelf gebruik port-knocking en de hierboven genoemde fail2ban oplossing, ook met aparte chain en address list. Het is niet anders, ik heb soms toegang nodig van buitenaf en niet altijd de mogelijkheid een VPN op te zetten.

Inventaris - Koop mijn meuk!

zaterdag 11 april 2026 16:08

Acties:

bl33d

I love the smell of Napalm..

TF0 schreef op maandag 6 april 2026 @ 23:14:
@Mit-46 Back to home is inderdaad een Wireguard tunnel. Ik heb hem zelf en bij iemand anders ingesteld, is echt heel simpel en werkt prima. Ik gebruik zelf liever de Wireguard app (op iOS) omdat die on demand is en kan gedefinieerde SSIDs uitsluiten. Op Android werkt dat niet, dus dan is Back to home prima.

Voordeel van Back to home is dat hij dynamisch is en dus niet gefixeerd is op je ip adres maar op basis van een adres binnen *.vpn.mynetname.net. Ik gebruik hem dus als backup voor als mijn externe ip adres verandert, dan kan ik in ieder geval het nieuwe adres vinden voor in de Wireguard app .

@jeroen3 Heb laatst toevallig naar Zerotier gekeken, maar daar moet je meteen voor betalen wat ik zag? Tailscale en Netbird zijn iets ‘vriendelijker’ wat dat betreft, maar niet (zo eenvoudig) in te stellen op een MikroTik.

In de Wireguard van Mikrotik kan je ook een ddns meegeven aan de peers. Dat is dynamisch. In de /Cloud heb je de optie om Mikrotiks versie van ddns te activeren. Dan hoef je nooit meer in je Wireguard client opnieuw een ip adres in te stellen.

zaterdag 11 april 2026 19:15

Acties:

TF0

bl33d schreef op zaterdag 11 april 2026 @ 16:08:
[...]

In de Wireguard van Mikrotik kan je ook een ddns meegeven aan de peers. Dat is dynamisch. In de /Cloud heb je de optie om Mikrotiks versie van ddns te activeren. Dan hoef je nooit meer in je Wireguard client opnieuw een ip adres in te stellen.

Hmm, ik had altijd mijn twijfels over die methode (url:poort klinkt a-intuïtief voor mij), maar het werkt op mijn telefoon (iOS) goed!

Ik zal t.z.t. eens kijken naar de site-to-site WireGuard tunnel die ik heb, dan hoef ik ook niets te doen als ik een andere provider krijg.

zaterdag 11 april 2026 20:37

Acties:

zaterdag 11 april 2026 20:39

Ik heb vandaag de default firewall regels vergeleken met mijn eigen regels en daar waar nodig mijn eigen aangevuld.
Zelf had ik meer regels (gevonden in video's en forums), maar toch niet alle default regels merkte ik.

Heb besloten ze naast elkaar te leggen en mijn eigen config aan te passen ipv opnieuw te beginnen en vervolgens de default config aan te vullen met wat ik al had.

Ik heb ook alle remote access uitgeschakeld en enkel Winbox ingeschakeld via lokale IP adressen. Dit lijkt mij het veiligst en scheelt een hoop firewall regels aangezien niets openstaat. Back To Home heb ik wel ingesteld.

Ik kwam op Youtube filmpjes tegen mbt port knocking en bruteforce protection.

Gezien ik alle remote access (en poorten) heb uitgeschakeld zijn de firewall regels m.b.t. port knocking en bruteforce protection toch niet nodig? Of zie ik dat verkeerd?

Ik heb zojuist een port scan gedaan m.b.v. de link die Kaaas heeft gedeeld en daar kwam enkel port 53 (DNS) naar voren.

DoH is me van de week niet gelukt , maar dat bewaar ik voor een volgende vakantie of lang weekend.

In ieder geval heb ik nu IPv4 en IPv6 ingesteld (ik heb KPN glasvezel btw), Wifi en LAN, firewall rules voor IPv4 en IPv6, alle remote access (op BTH na) uitgeschakeld en zoveel mogelijk poorten dichtgezet (ftp, etc.).

Ik heb van de week wel gemerkt dat ik soms s'morgens kort geen internetverbinding heb. Meestal is het weer terug nog voordat ik mijn bed uit ben. Hopelijk is dat na het aanpassen van de firewall regels nu ook opgelost en anders moet ik daar nog wel naar kijken.

Hopelijk voor nu even klaar met het RouterOS avontuur. Het waren een paar intensieve weken en met name afgelopen week

In de toekomst (nog ver weg) eens kijken naar een wifi 7 apparaat.

Ben voor nu wel blij.
Iedereen bedankt voor de tips and trics. $_/-\o_$

Acties:

chaoscontrol

Mit-46 schreef op zaterdag 11 april 2026 @ 20:37:

Ik heb zojuist een port scan gedaan m.b.v. de link die Kaaas heeft gedeeld en daar kwam enkel port 53 (DNS) naar voren.

Snel dichtzetten extern. Anders ga je gebruikt worden in DNS amplification attacks en gooit je provider je verbinding dicht.

Inventaris - Koop mijn meuk!

zaterdag 11 april 2026 20:44

Acties:

zondag 12 april 2026 08:58

chaoscontrol schreef op zaterdag 11 april 2026 @ 20:39:
[...]

Snel dichtzetten extern. Anders ga je gebruikt worden in DNS amplification attacks en gooit je provider je verbinding dicht.

Ik heb 2 firewall regels aangemaakt, omdat ik dit op Youtube heb gezien.

Zijn die niet nodig?

code:

10    ;;; Allow DNS to local (TCP)
      chain=input action=accept protocol=tcp in-interface-list=LAN-list dst-port=53 log=no log-prefix="" 

11    ;;; Allow DNS to local (UDP)
      chain=input action=accept protocol=udp in-interface-list=LAN-list dst-port=53 log=no log-prefix="" 

-- [Q quit|D dump|up|down]

edit:
Had alle regels gepost, maar bedacht mij dat dit misschien niet zo slim is.

Edit 2:
Ik heb bovenstaande 2 regels disabled en twee rules Gegoogled om poort 53 te blokkeren via de WAN list interface list.

Ze krijgen nu ook een time out (net als alle andere common ports).

Dank voor de tip

[ Voor 84% gewijzigd door Mit-46 op 11-04-2026 21:03 ]

Acties:

zondag 12 april 2026 09:05

in plaats van specifieke poorten dicht te zetten, moet je uitgangspunt eigenlijk zijn dat alle verkeer inkomend op de WAN wordt geblocked, en ga je daarna waar nodig (als het al nodig is) specifieke poorten openzetten.

in je forward chain:
/ip firewall filter add chain=forward in-interface=WAN connection-nat-state=!dstnat action=drop

in je input chain:
/ip firewall filter add chain=input in-interface=WAN action=drop

dit moeten je laatste regels zijn in beide chains
filter je chains zo dat alle rules bij elkaar staan, dit is makkelijker lezen en zo zorg je ook dat aan het eind van de chains je block rules staan

Acties:

zondag 12 april 2026 11:04

Mit-46 schreef op zaterdag 11 april 2026 @ 20:44:
[...]

Had alle regels gepost, maar bedacht mij dat dit misschien niet zo slim is.

zolang je niet je ip adres en wachtwoorden post is er niet veel aan de hand en je krijgt veel betere feedback (als het niet hier is, post dan je config ook op het mikrotik forum )

naast tweakers kan je ook je config posten op het mikrotik forum voor feedback en verbeteringen.

Acties:

lier

MikroTik nerd

MikroTik
Wifi

Persoonlijk heb ik zowel input als forward chain afgesloten zonder de in-interface(-list):

code:

1 2	/ip firewall filter add chain=input action=drop /ip firewall filter add chain=forward action=drop

Daarmee weet je (wel) zeker dat alles, dat je niet expliciet toestaat, geblokkeerd wordt.

zolang je niet je ip adres en wachtwoorden post is er niet veel aan de hand

Serial nummer wil je niet en private keys moet je ook niet te vergeten. Gelukkig is onder RouterOS V7 export zonder deze info (en moet je show-sensitive toevoegen als argument om het wel te laten zien).

Ben trouwens zelf niet zoń voorstander van port knocking of lijsten bijhouden. Maar ieder zijn ding.

Eerst het probleem, dan de oplossing

zondag 12 april 2026 11:19

Acties:

Jef61

lier schreef op zondag 12 april 2026 @ 11:04:
Persoonlijk heb ik zowel input als forward chain afgesloten zonder de in-interface(-list):
code:
1
2
/ip firewall filter add chain=input action=drop
/ip firewall filter add chain=forward action=drop
Daarmee weet je (wel) zeker dat alles, dat je niet expliciet toestaat, geblokkeerd wordt.

Ja zo eindig ik de firewall rules ook (en IPv6 hetzelfde):

code:

1 2	/ipv6 firewall filter add action=drop chain=forward /ipv6 firewall filter add action=drop chain=input

zondag 12 april 2026 17:18

Acties:

zondag 12 april 2026 18:18

Dank weer voor de info. Ik zal zo eens kijken hoe ik de export correct kan maken.
Het werkt allemaal nog niet goed dus kan wel wat hulp gebruiken.
Vandaag maakt BTH opeens geen verbinding meer dus geen idee wat ik gister heb gedaan waardoor dit nu weer is ontstaan.
Per toeval op de trail and error toer kom ik erachter dat BTH de poort van Winbox nodig heeft. Die heb ik gister gewijzigd naar iets anders. Ik heb de nieuwe poort achter het IP adres geplakt in de app en daarmee kan ik weer verbinding maken.

Ook heb ik (nog steeds) dat apparaten soms geen internetverbinding meer hebben. Ik denk dat het alleen apparaten zijn die via wifi verbonden zijn, maar ik kan er niet echt de vinger op leggen.
Het valt mij vooral op bij telefoons in de ochtend als ik net wakker wordt. Soms heeft de ene wel internet en de andere niet terwijl ze beide met hetzelfde wifi netwerk verbonden zijn. Ik heb de 5G verbinding uitgesloten/uitgeschakeld bij het testen.

Het gebeurt soms ook met mijn laptop. Ik kan op zulke momenten wel verbinden met Winbox en lokaal werkt alles. In Winbox zie ik verder geen bijzondere meldingen in de logs. Althans niet voor zover ik het begrijp.

Het is niet zo dat de hele internetverbinding eruit ligt, want mijn NUC die verbonden is via ethernet blijft het gewoon doen als bijvoorbeeld de laptop de verbinding verliest. Zelfs niet alle wifi apparaten verliezen de verbinding.
Soms meerdere tegelijk, maar soms ook niet. Voor mijn gevoel is het ook compleet random (maar dit zal ongetwijfeld niet zo zijn, wanneer duidelijk is waar het aan ligt).

Heftig spul dat Mikrotik

[ Voor 16% gewijzigd door Mit-46 op 12-04-2026 19:53 ]

Acties:

zondag 12 april 2026 21:38

Dit is de /ip firewall en ook de /ip service config.

Doordat ik onderaan de /ip firewall service ports zag staan, met in eerste instantie alleen ftp en tftp, heb ik daar zojuist ook onderstaande 3 aan toegevoegd.
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes

Als ik het goed lees zijn die voor VOIP en een verouderd VPN protocol. Ik denk dat dit slim is, maar weten doe ik eigenlijk (nog) niet

(Als ik het goed lees/begrijp heeft het geen effect op bijvoorbeeld Discord VOIP).

Mocht iemand zin hebben om het te beoordelen zou ik dat heel fijn vinden. $_/-\o_$
Volgens mij klopt de volgorde van de laatste 3 forward regels niet.

Ik heb IP adressen, poorten en andere cijfertjes weggehaald voor mijn eigen gemoedsrust. Welke er wel staan zijn gewijzigd op de port 53 na regels na.

code:

/ip firewall filter
add action=accept chain=input comment=\
    "Connection state established-related - untracked-ACCEPT" \
    connection-state=established,related,untracked
add action=drop chain=input comment="Connection state - Invalid - DROP" \
    connection-state=invalid
add action=accept chain=input comment=Ping-ACCEPT protocol=icmp
add action=accept chain=input comment="Local loopback for CAPsMAN - ACCEPT" \
    dst-address=0.0.0.0 in-interface=lo src-address=0.0.0.0
add action=add-src-to-address-list address-list=port_scanners \
    address-list-timeout=1d chain=input comment="Add port scanners to list" \
    protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop port scanners" src-address-list=\
    port_scanners
add action=accept chain=input comment="LAN=list -ACCEPT" in-interface-list=\
    LAN-list
add action=drop chain=input comment="DROP all not coming from LAN-list" \
    in-interface-list=!LAN-list
add action=drop chain=input comment="WAN DNS port 53 UDP DROP" dst-port=53 \
    in-interface-list=WAN-list protocol=udp
add action=drop chain=input comment="WAN DNS port 53 TCP DROP" dst-port=53 \
    in-interface-list=WAN-list protocol=tcp
add action=drop chain=input comment="WAN (ether1) to router- DROP ALL" \
    in-interface-list=WAN-list

add action=accept chain=forward comment="IPSEC policy IN - ACCEPT" \
    ipsec-policy=in,ipsec
add action=drop chain=forward comment="IPSEC policy OUT - ACCEPT" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=\
    "Fasttrack - established - related" connection-state=established,related
add action=accept chain=forward comment=\
    "Connection state established-related-untracked ACCEPT" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="Connection state - Invalid - DROP" \
    connection-state=invalid
add action=accept chain=forward comment="LAN to WAN - ACCEPT (2)" \
    in-interface-list=LAN-list out-interface-list=WAN-list
add action=drop chain=forward comment="DROP all not coming from LAN-list" \
    in-interface-list=!LAN-list
add action=drop chain=forward comment="DROP all from WAN not DSTNATed" \
    connection-nat-state=!dstnat in-interface-list=WAN-list
add action=drop chain=input comment="Block Winbox default port 8291" \
    dst-port=8291 in-interface=ether1 protocol=tcp

/ip firewall nat
add action=masquerade chain=srcnat comment=Masquerade out-interface=\
    pppoe-client

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes


/ip service
set ftp disabled=yes
set ssh disabled=yes
set telnet disabled=yes
set www disabled=yes
set winbox address=ipadresshere max-sessions=*** port=notdefault
set api disabled=yes
set api-ssl disabled=yes

/ip service webserver
set graphs-plain=no graphs-secure=no rest-plain=no rest-secure=no \
    webfig-plain=no webfig-secure=no

Acties:

zondag 12 april 2026 22:49

Heb je DOH per ongeluk al ingesteld?
Mikrotik ondersteund geen http/2 als je dan een doh servergebruikt die http/2 is krijg je echt vage dingen. Zoals soms wel en soms geen werkende dns/internet
Als het goed is krijgt ROS 7.23 DOH http/2 support.

[ Voor 11% gewijzigd door kaaas op 12-04-2026 21:40 ]

Acties:

maandag 13 april 2026 11:16

Ik had het wel ingesteld, maar weer weggehaald, omdat het niet werkte.

Dit zijn nu mijn DNS instellingen:

code:

/IP DNS 
servers: 9.9.9.9         149.112.112.112 (Quad 9 DNS servers)
dynamic-servers:                
use-doh-server:                
verify-doh-cert: no             
doh-max-server-connections: 5              
doh-max-concurrent-queries: 50             
doh-timeout: 5s             
allow-remote-requests: yes            
max-udp-packet-size: 4096           
query-server-timeout: 2s             
query-total-timeout: 10s            
max-concurrent-queries: 100            
max-concurrent-tcp-sessions: 20             
cache-size: 2048KiB        
cache-max-ttl: 1w             
address-list-extra-time: 0s             
vrf: main           
mdns-repeat-ifaces:                
cache-used: 47KiB

Onder /IP DHCP server / Networks heb ik in de netwerkinstellingen onder DNS het lokale IP adres van de router ingevoerd.

(Peer DNS staat uit in interface van PPPOE client.)

Vandaag heeft alles de hele dag gewerkt zonder hickup op de ochtend na bij 1 telefoon.

Acties:

maandag 13 april 2026 11:31

Ik zou je logs checken op dns issues, maar het hoeft natuurlijk helemaal geen dns probleem te zijn, het is maar een gok. Dus kijk ook vooral ff verder in je logs.

code:

1	/log/print where topics~"dns"

Acties:

maandag 13 april 2026 11:43

kaaas schreef op maandag 13 april 2026 @ 11:16:
Ik zou je logs checken op dns issues, maar het hoeft natuurlijk helemaal geen dns probleem te zijn, het is maar een gok. Dus kijk ook vooral ff verder in je logs.
code:
1
/log/print  where topics~"dns"

Toeval of niet, maar ik ben vandaag weer aan het werk na een week vakantie en ook vanaf huis.
Voor het eerst sinds ik de router in gebruik heb genomen.

Vanochtend weer mijn Fairphone die geen internet had terwijl de Huawei wel. Viel mij als eerst op dat de Fairphone via 5Ghz verbonden was en de oude Huawei via 2Ghz dus wilde daar in gaan duiken.

Geen tijd voor gehad, want moest aan de bak, maar vervolgens verliest mijn werk laptop continu de verbinding.

Nu heb ik tot 2 maal toe de Windows DNS instelling gewijzigd van automatisch naar handmatig 8.8.8.8 en dat lost het probleem op!

Sterker nog, Edge kan dan wel verbinden met het internet, maar LibreWolf niet. In LibreWolf heb ik DoH ingesteld via ook Quad 9 (met malware protection). Op het moment dat ik dit uitschakel in de browser kan ook LibreWolf verbinden naar het internet (met dus 8.8.8.8 als DNS).

Mijn hele avontuur om van router en AP te gaan wisselen was omdat ik DNS problemen had. Heel specifiek met Quad 9.

Ik denk dat ik nu wel kan concluderen dat de problemen vooral aan Quad9 liggen, want ik heb een nieuwe router (met ingebouwd AP) en nog steeds DNS problemen met Quad9 zo lijkt het.

Dit speelt al de hele tijd sinds ik de router gebruik en als ik terugdenk dan heb ik ook een poging gedaan met de peer DNS instelling (dus van KPN) en dan had ik geen problemen. Dit was ook mijn tijdelijke oplossing met mijn oude Ubiquiti router en Netgear AP (Quad9 niet gebruiken).

Ik ga straks de DNS van DNSbunker proberen en kijken of dit verschil maakt. In LibreWolf heb ik nu Mullvad ingesteld als DoH. Even aankijken.

Ik zal straks ff op mijn eigen laptop kijken naar de DNS log zoals je hebt aangegeven.

edit:
Ik zie dat ik op Android (ik gebruik /e/OS) ook de DNS instellingen kan wijzigen. Ik zal deze vanavond voor ik ga slapen wijzigen naar 1.1.1.1 zodat ik morgenochtend kan kijken of ik wel internet heb aangezien het altijd in de ochtend niet werkt.

[ Voor 15% gewijzigd door Mit-46 op 13-04-2026 11:54 ]

Acties:

maandag 13 april 2026 11:45

Ik was te lui om het daadwerkelijk probleem uit te zoeken, maar ik had na doh geconfigureerd te hebben met een http/2 provider ook nog problemen nadat ik doh had uit gezet en een normale dns provider had ingesteld. Pas toen ik weer terug ging naar DOH zonder http/2 waren mijn problemen over. Iets gaat daar niet helemaal goed.

Acties:

lier

MikroTik nerd

MikroTik
Wifi

kaaas schreef op maandag 13 april 2026 @ 11:43:
Iets gaat daar niet helemaal goed.

HTTP/2 ondersteuning vanaf V7.23, nog heel even geduld of met de beta werken.

Eerst het probleem, dan de oplossing

maandag 13 april 2026 18:04

Acties:

maandag 13 april 2026 19:54

Mit-46 schreef op zondag 12 april 2026 @ 18:18:
Dit is de /ip firewall en ook de /ip service config.

Doordat ik onderaan de /ip firewall service ports zag staan, met in eerste instantie alleen ftp en tftp, heb ik daar zojuist ook onderstaande 3 aan toegevoegd.
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes

Als ik het goed lees zijn die voor VOIP en een verouderd VPN protocol. Ik denk dat dit slim is, maar weten doe ik eigenlijk (nog) niet

Ik heb IP adressen, poorten en andere cijfertjes weggehaald voor mijn eigen gemoedsrust. Welke er wel staan zijn gewijzigd op de port 53 na regels na.

code:

/ip firewall filter
add action=accept chain=input comment=\
    "Connection state established-related - untracked-ACCEPT" \
    connection-state=established,related,untracked
add action=drop chain=input comment="Connection state - Invalid - DROP" \
    connection-state=invalid
add action=accept chain=input comment=Ping-ACCEPT protocol=icmp
add action=accept chain=input comment="Local loopback for CAPsMAN - ACCEPT" \
    dst-address=0.0.0.0 in-interface=lo src-address=0.0.0.0
add action=add-src-to-address-list address-list=port_scanners \
    address-list-timeout=1d chain=input comment="Add port scanners to list" \
    protocol=tcp psd=21,3s,3,1
add action=drop chain=input comment="Drop port scanners" src-address-list=\
    port_scanners
add action=accept chain=input comment="LAN=list -ACCEPT" in-interface-list=\
    LAN-list
add action=drop chain=input comment="DROP all not coming from LAN-list" \
    in-interface-list=!LAN-list
add action=drop chain=input comment="WAN DNS port 53 UDP DROP" dst-port=53 \
    in-interface-list=WAN-list protocol=udp
add action=drop chain=input comment="WAN DNS port 53 TCP DROP" dst-port=53 \
    in-interface-list=WAN-list protocol=tcp
add action=drop chain=input comment="WAN (ether1) to router- DROP ALL" \
    in-interface-list=WAN-list

add action=accept chain=forward comment="IPSEC policy IN - ACCEPT" \
    ipsec-policy=in,ipsec
add action=drop chain=forward comment="IPSEC policy OUT - ACCEPT" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=\
    "Fasttrack - established - related" connection-state=established,related
add action=accept chain=forward comment=\
    "Connection state established-related-untracked ACCEPT" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="Connection state - Invalid - DROP" \
    connection-state=invalid
add action=accept chain=forward comment="LAN to WAN - ACCEPT (2)" \
    in-interface-list=LAN-list out-interface-list=WAN-list
add action=drop chain=forward comment="DROP all not coming from LAN-list" \
    in-interface-list=!LAN-list
add action=drop chain=forward comment="DROP all from WAN not DSTNATed" \
    connection-nat-state=!dstnat in-interface-list=WAN-list
add action=drop chain=input comment="Block Winbox default port 8291" \
    dst-port=8291 in-interface=ether1 protocol=tcp

/ip firewall nat
add action=masquerade chain=srcnat comment=Masquerade out-interface=\
    pppoe-client

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes


/ip service
set ftp disabled=yes
set ssh disabled=yes
set telnet disabled=yes
set www disabled=yes
set winbox address=ipadresshere max-sessions=*** port=notdefault
set api disabled=yes
set api-ssl disabled=yes

/ip service webserver
set graphs-plain=no graphs-secure=no rest-plain=no rest-secure=no \
    webfig-plain=no webfig-secure=no

net als je input en forward regels bij elkaar te houden, doe hetzelfde met de accepts en drops in deze chains.
dus
chain input
- alle accept rules
- alle drop rules
chain forward
- alle accept rules
- alle drop rules

het principe is, alles is dicht door
/ip firewall filter add chain=input action=drop
/ip firewall filter add chain=forward action=drop
en dan ga je daarboven alleen die poorten open zetten die je nodig hebt

regels 10 en 13 kunnen volgens mij weg. want zie hierboven
zelfde geldt voor je DNS regels 19 & 21 (weet ik niet zeker, ik draai zelf een pihole met unbound voor dns, dus niet op de mikrotik )

regel 43 kan weg, want je dropt daarboven alles al
(had je niet je vpn op die poort zitten trouwens ? )
regel 37 omhoog: accept boven de drop rules

als je in winbox werkt, zet ook even fail safe aan. mocht je een fout maken kan je er na de timeout altijd weer terug in.

als je je firewall rules hebt aangepast, wel altijd weer even een goede poort-scan doen!

Acties:

pimlie

@Mit-46 Volgorde van rules is ook belangrijk, RouterOS moet elke rule in een chain doorlopen van boven naar beneden. Het loont dus om je meest gebruikte rules (fast-connection & accept established/related) bovenaan te zetten zodat het meeste verkeer direct bij de eerste of tweede rule gematched wordt.

Let wel dit is per chain, je kan dus gewoon zoals @ronjon aangeeft input/forward rules groeperen.

maandag 13 april 2026 21:30

Acties:

zaterdag 18 april 2026 14:36

kaaas schreef op maandag 13 april 2026 @ 11:16:
Ik zou je logs checken op dns issues, maar het hoeft natuurlijk helemaal geen dns probleem te zijn, het is maar een gok. Dus kijk ook vooral ff verder in je logs.
code:
1
/log/print  where topics~"dns"

Ik ben hierin gedoken. Wist niet dat je de DNS ook kon loggen.
Er kwam een aantal keer "failure" naar voren mbt DNS en ik ben eigenlijk de hele avond aan het stoeien met verschillende DNS servers.
Lang verhaal kort; ik heb nu de standaard KPN servers ingesteld om te kijken of het nu (langdurig) stabiel draait en dit als basis te gebruiken om eventueel later andere te proberen.

Dank voor de tip. Weer wat geleerd. Super nuttig

ronjon schreef op maandag 13 april 2026 @ 18:04:
[...]
net als je input en forward regels bij elkaar te houden, doe hetzelfde met de accepts en drops in deze chains.
dus
chain input
- alle accept rules
- alle drop rules
chain forward
- alle accept rules
- alle drop rules

het principe is, alles is dicht door
/ip firewall filter add chain=input action=drop
/ip firewall filter add chain=forward action=drop
en dan ga je daarboven alleen die poorten open zetten die je nodig hebt

regels 10 en 13 kunnen volgens mij weg. want zie hierboven
zelfde geldt voor je DNS regels 19 & 21 (weet ik niet zeker, ik draai zelf een pihole met unbound voor dns, dus niet op de mikrotik )

regel 43 kan weg, want je dropt daarboven alles al
(had je niet je vpn op die poort zitten trouwens ? )
regel 37 omhoog: accept boven de drop rules

als je in winbox werkt, zet ook even fail safe aan. mocht je een fout maken kan je er na de timeout altijd weer terug in.

als je je firewall rules hebt aangepast, wel altijd weer even een goede poort-scan doen!

Dank dat je de moeite hebt genomen om er doorheen te gaan $_/-\o_$
Ik heb regel 37 meteen (1 plaats) omhoog geplaatst. Doordat ik nu ook de DNS servers heb aangepast wil ik niet teveel tegelijk wijzigen, want anders weet ik niet wat nu welk effect heeft gehad.

Ik wil het zaterdag allemaal gaan aanpassen. Ik wist niet dat je alle accepts en drops van dezelfde chain onder elkaar kon zetten. Ik dacht juist dat het zo moest zoals ik het nu heb vanwege de volgorde die bepalend is.

Ik ga het zaterdag allemaal netjes maken en naar de andere regels kijken die je hebt genoemd . $_/-\o_$

pimlie schreef op maandag 13 april 2026 @ 19:54:
@Mit-46 Volgorde van rules is ook belangrijk, RouterOS moet elke rule in een chain doorlopen van boven naar beneden. Het loont dus om je meest gebruikte rules (fast-connection & accept established/related) bovenaan te zetten zodat het meeste verkeer direct bij de eerste of tweede rule gematched wordt.

Let wel dit is per chain, je kan dus gewoon zoals @ronjon aangeeft input/forward rules groeperen.

Ga ik doen. Dank ook voor deze tips!! $_/-\o_$

Acties:

zaterdag 18 april 2026 15:36

Ik heb de firewall rules netjes geordend en ben deze week toch wat wezen spelen met de andere instellingen. De firewalls zien er nu inderdaad veel rustiger/overzichtelijker uit.

Ik had ook opgemerkt dat de IPv6 instellingen (mbt de IPv6 pool) niet goed stonden en dit heb ik gepast. Ik zie alleen nog best veel "failed" met MAC address 00:00:00:00:00 staan in IPv6/Neighbours, maar ik verdenk 1 of 2 IoT apparaatjes die zijn gekoppeld aan mijn Home Assistant. Dat moet ik nog uitzoeken.

Op mijn Windows 11 (werk) laptop na heeft geen van mijn computers (allemaal Linux Mint) en telefoons na deze wijzigingen nog verbindingsproblemen met IPv6 gehad (volgens de /IPv6/Neighbours lijst).

De werklaptop is een beheerd apparaat dus geen idee of daardoor IPv6 niet lekker werkt. Het apparaat krijgt wel een IPv6 adres, maar kan daarna volgens de logs niet meer verbinden met de router via IPv6 (failed staat er bij het IP adres in de router).

Gister heb ik ook de DNS instellingen weer aangepast door niet meer naar de router te laten verwijzen, maar direct naar Quad9.
Ik heb het idee dat ik sindsdien met geen enkel apparaat meer "internet issues" heb gehad. Ook niet met de W11 werklaptop terwijl ik voor deze wijziging gister nog wel issues had met deze laptop.

Ik heb nu 2 (Quad9) IPv4 en 2 IPv6 DNS servers ingesteld onder /IP/DNS en in /IP/DHCP server/Networks. Geen idee of dit dubbel en onzinnig is. Allow remote requests heb ik nu ook uitgeschakeld.
Moet het nog wel een paar dagen aankijken, maar "so far, so good".

Ook heb ik geprobeerd de wifi instellingen wat te tweaken. Ik heb de DFS channels uitgeschakeld en handmatig specifieke kanalen ingesteld voor zowel 2.4Ghz als 5Ghz.
Ik heb het idee dat het misschien een beetje geholpen heeft. Het is in ieder geval niet slechter geworden. De gemiddelde speedtest zit op 650mbps met een uitschieter gister rond de 750mbps, maar dat is daarna niet meer gelukt. Op zich prima voor dit goedkope wifi 6 apparaatje, denk ik.

Met de tijd eens op zoek naar een high end wifi 6 AP oid.

Het enige wat mij nu nog stoort zijn de meldingen: denied winbox/dude connect from 64.62.197.32 (met telkens een ander IP adres). Zijn die meldingen te voorkomen?
Ik zit ook vaak naar de logs te kijken en misschien moet ik dat gewoon niet doen. Deed ik met andere routers ook nooit, maar zit nu helemaal "in RouterOS"

De firewall doet zijn werk, maar het liefst zou ik willen dat ze helemaal niet kunnen proberen te verbinden.
Alles mbt Winbox is (volgens mij) dichtgezet. Een andere poort, neighbours discovery staat uit en het is alleen vanaf LAN te openen.
Af en toe zie ik nog zo'n poging voorbijkomen.
Alle andere mogelijke pogingen zie ik niet meer voorbijkomen in de logs.

Het heeft wat moeite gekost, maar ben inmiddels heel blij met de Mikrotik router.
Nogmaals dank voor jullie hulp allemaal!

[ Voor 7% gewijzigd door Mit-46 op 18-04-2026 20:12 ]

Acties:

babbelbox

@Mit-46
Als je denied meldingen krijgt lijkt het mij dat het verkeer door je firewall heen komt.
Kijk naar je input chain, daar alleen intern toestaan en de rest droppen.

P.s. misschien verstandig je public IP te verwijderen

[ Voor 17% gewijzigd door babbelbox op 18-04-2026 15:37 ]

zaterdag 18 april 2026 15:49

Acties:

zaterdag 18 april 2026 16:26

babbelbox schreef op zaterdag 18 april 2026 @ 15:36:
@Mit-46
Als je denied meldingen krijgt lijkt het mij dat het verkeer door je firewall heen komt.
Kijk naar je input chain, daar alleen intern toestaan en de rest droppen.

P.s. misschien verstandig je public IP te verwijderen

Interessant

Ik kan zo gauw niet vinden hoe ik mijn public IP kan verwijderen. Deze is dynamisch via pppoe. Als ik deze verwijder uit /IP/adresses dan valt mijn internetverbinding uit.

Daarnaast dacht ik dat ik de firewall al zo had ingesteld. Schijnbaar dus niet. Wat jammer

Ga ik daar maar weer naar kijken. Dank voor de tip.

Acties:

zaterdag 18 april 2026 16:27

publieke IP kan je niet verwijderen zelf. ik denk dat @babbelbox bedoelt het ip adres in je bericht.

voor winbox / dude connecties lijkt t inderdaad dat er ergens nog altijd een poort open staat.
kijk even bij /ip/services in winbox en of je daar bij "available from" iets hebt staan.

je kan daar ook instellen dat je alleen je interne netwerk toegang wil geven

bij mij staat er dit als ik in een console /ip/services/print geef

code:

1
2
3

14     winbox                8291  tcp    192.168.0.0/24                    main            20                                 
                                          10.0.0.0/24                                                                          
                                          192.168.110.240/28

Acties:

jeroen3

@Mit-46 ik denk dat @babbelbox bedoelt dat je jouw ip niet hier hier moet posten.

Die denied melding betekent dat je firewall niet deugt. Kijk even of alle default regels nog in de juiste volgorde staan (sorteer op #), en dat je geen te brede accept regels hebt toegevoegd op de verkeer plek.
En dat je niet per ongeluk je interface lists kapot hebt gemakt waardoor de catch-all niet meer werkt:

code:

1	defconf: drop all from WAN not DSTNATed

[ Voor 3% gewijzigd door jeroen3 op 18-04-2026 16:27 ]

zaterdag 18 april 2026 16:30

Acties:

zaterdag 18 april 2026 16:34

post je firewall rules hier anders eens

/ip/firewall/export

en maskeer of verwijderen dan eerst even alle data die je niet wilt delen

Acties:

zaterdag 18 april 2026 16:50

Ah!
64.62.197.32 is niet mijn IP adres, maar het IP adres waarmee geprobeerd werd te verbinden.

Ik schrok al

Mijn Winbox is alleen beschikbaar vanaf mijn lokale LAN : 1**.**.*.***/24 en ook met een eigen verzonnen poort.
9 winbox **** tcp 19*********/24 main 2
10 D c winbox **** tcp 19************ 19********4*****0

Ik zal eens mijn rules posten. Ik zet wel eerst een back up terug, want anders wordt het erg verwarrend allemaal.

[ Voor 77% gewijzigd door Mit-46 op 18-04-2026 20:16 ]

Acties:

zaterdag 18 april 2026 17:18

code:

Flags: X - DISABLED, I - INVALID; D - DYNAMIC 
 0  D ;;; back-to-home-vpn
      chain=input action=accept protocol=udp dst-port=46882 

 1  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 2    ;;; Connection state established-related - untracked-ACCEPT
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 3    ;;; Ping-ACCEPT
      chain=input action=accept protocol=icmp log=no log-prefix="" 

 4    ;;; Local loopback for CAPsMAN - ACCEPT
      chain=input action=accept src-address=127.0.0.1 dst-address=127.0.0.1 in-interface=lo log=no log-prefix="" 

 5 X  ;;; Add port scanners to list
      chain=input action=add-src-to-address-list protocol=tcp psd=21,3s,3,1 address-list=port_scanners address-list-timeout=1d log=no log-prefix="" 

 6    ;;; LAN=list -ACCEPT
      chain=input action=accept in-interface-list=LAN-list log=no log-prefix="" 

 7    ;;; Connection state - Invalid - DROP
      chain=input action=drop connection-state=invalid log=no log-prefix="" 

 8 X  ;;; Drop port scanners
      chain=input action=drop src-address-list=port_scanners log=no log-prefix="" 

 9    ;;; DROP all not coming from LAN-list
      chain=input action=drop in-interface-list=!LAN-list log=no log-prefix="" 

10 X  ;;; WAN DNS port 53 UDP DROP
      chain=input action=drop protocol=udp in-interface-list=WAN-list dst-port=53 log=no log-prefix="" 

11 X  ;;; WAN DNS port 53 TCP DROP
      chain=input action=drop protocol=tcp in-interface-list=WAN-list dst-port=53 log=no log-prefix="" 

12    ;;; WAN-list to router- DROP ALL
      chain=input action=drop in-interface-list=WAN-list log=no log-prefix="" 

13    ;;; Fasttrack - established - related
      chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix="" 

14    ;;; Connection state established-related-untracked ACCEPT
      chain=forward action=accept connection-state=established,related,untracked log=no log-prefix="" 

15    ;;; IPSEC policy IN - ACCEPT
      chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec 

16    ;;; LAN to WAN - ACCEPT (2)
      chain=forward action=accept in-interface-list=LAN-list out-interface-list=WAN-list log=no log-prefix="" 

17    ;;; IPSEC policy OUT - ACCEPT
      chain=forward action=drop log=no log-prefix="" ipsec-policy=out,ipsec 

18    ;;; Connection state - Invalid - DROP
      chain=forward action=drop connection-state=invalid log=no log-prefix="" 

19    ;;; DROP all not coming from LAN-list
      chain=forward action=drop in-interface-list=!LAN-list log=no log-prefix="" 

20    ;;; DROP all from WAN not DSTNATed
      chain=forward action=drop connection-nat-state=!dstnat in-interface-list=WAN-list log=no log-prefix="" 

21    ;;; Block Winbox default port 8291
      chain=input action=drop protocol=tcp in-interface-list=WAN-list dst-port=8291 log=no log-prefix="" 

22    ;;; Block Winbox default port 5678
      chain=input action=drop protocol=udp in-interface-list=all dst-port=8291 log=no log-prefix="" 

/ip firewall nat
add action=masquerade chain=srcnat comment=Masquerade out-interface=pppoe-client-KPN

/ip firewall service-port
set ftp disabled=yes
set tftp disabled=yes
set h323 disabled=yes
set sip disabled=yes
set pptp disabled=yes

De laatste 2 regels mbt Winbox zijn de default poorten (volgens het internet). Dit is niet de poort welke ik nu gebruik.
Ik zie overigens nu dat de laatste regel helemaal niet klopt (poort en beschrijving).

Wat betreft de interface list heb ik er 2:
LAN-list en daar zitten de ethernet interfaces vanaf #2 en de 2 wifi interfaces in. Ook de Lan-Wifi bridge (zie hieronder) en de Back-to-home-vpn interface

WAN-list en daar zit de PPPOE interface en vlan 6 interface in.

Eth1 heb ik nergens aan toegevoegd, maar de vlan 6 interface is wel gekoppeld aan de eth1 interface onder interfaces.

Als bridge heb ik alleen één bridge met de interfaces vanaf eth2 en de 2 wifi interfaces
Hier geen PPPOE of vlan 6 oid.

*edit:
Wat overzichtelijker gemaakt.

[ Voor 92% gewijzigd door Mit-46 op 18-04-2026 17:18 ]

Acties:

zaterdag 18 april 2026 17:22

ik zou
- regel 3: ping accept weghalen (waarom je wil een ping accepteren van buiten af. je maakt alleen maar kenbaar dat er achter dat ip adres dus een systeem zit ), of alleen accepteren vanuit je LAN
- regel 15 + 17: ipsec inbound accepteer je, outbound (17) drop je. je vpn werkt niet als je het zo instelt lijkt me. als je 17 ook accept zou vpn moeten werken
- regel 9 dropt alles wat niet van de LAN list komt, regel 12 dropt alles van WAN (maar wordt nooit geraakt want regel 9 zorgt hier al voor
- regel 22: je comment is niet gelijk aan de poort die je blocked. (5678) cosmetics maar ik zou het goed willen hebben staan

regels 21+22: in plaats van Winbox in je firewall te blocken kan je het in de service ook doen door een intern adres-reeks toe te wijzen
/ip service set winbox address=192.168.0.0/16 (als je in de 192.168.x.x range zit )
daarmee zou je ook geen connecties meer moeten krijgen van het ip adres wat je eerder noemde

Acties:

jeroen3

@ronjon als ik het zo zie zouden deze rules geen traffic mogen toelaten tot de winbox api vanaf wan, toch zijn er inlog pogingen. Dus mogelijk staan de interface lists verkeerd.

[ Voor 6% gewijzigd door jeroen3 op 18-04-2026 17:23 ]

zaterdag 18 april 2026 17:28

Acties:

zaterdag 18 april 2026 17:45

@jeroen3 je hebt gelijk. maar als ik het goed begreep dan heeft @Mit-46 winbox op een andere poort staan dan de standaard 8291

als dat zo is, dan verklaart dat de connectie pogingen misschien wel weer.
(en hebben rules 21 en 22 dus helemaal geen toegevoegde waarde )

@Mit-46 welke poort heb je aan winbox toegewezen ?
/ip/services/print

Acties:

jeroen3

@ronjon Als het goed is matcht tcp verkeer voor winbox van buitenaf geen enkele input regel, en dropt dit dus op regel 12.
Ook als je een andere dan default poort gerbuikt.
Stel je zou winbox vanaf WAN willen moet je een input accept maken en deze boven regel 12 zetten.
Dus ergens klopt nog iets niet.
Regel 21 en 22 zijn zinloos, tenzij je expliciet ook tcp hole-punching wil blokkeren. (dat is dan een gerichte aanval, men zit dan al op je lan)

zaterdag 18 april 2026 17:52

Acties:

zaterdag 18 april 2026 17:58

Dank jullie wel voor het controleren!

Regel 3 heb ik aangepast. Dit moet inderdaad alleen van de LAN-list zijn. Deze heb ik nu gekoppeld aan de LAN-list.
Ik lees dat de icmp functionaliteit nodig is. Is dit niet zo? Dan wis ik die regels namelijk. Ik ben nu in de veronderstelling dat het nodig is (ik heb IPv6 ingesteld).

Ik lees dit op Google:
"allowing specific ICMP types in a MikroTik firewall is necessary for network functionality, not just diagnostic pings. It is critical for Path MTU Discovery (PMTUD) to prevent fragmentation issues and for error reporting. Blocking all ICMP can break connectivity, particularly in IPv6"

Regel 15-17 heb ik nu nog even niets mee gedaan, want de BTH VPN doet het wel. Daar heb ik momenteel geen problemen mee (nu net ff dubbel gecheckt en ik kan gewoon verbinden vanaf mijn telefoon via 5G met wifi uitgeschakeld).

Regel 12 heb nu disabled.

Regel 22 heb ik aangepast naar 5678 zoals de beschrijving aangeeft. Ik las dat dit de standaard UDP poort is voor Winbox en dat 8291 de standaard TCP poort is.
Deze regels zijn ontstaan uit een poging de inlogpogingen te stoppen. Mijn poort was al gewijzigd toen ik deze regels aanmaakte dus ze doen eigenlijk niets is nu gebleken. Verwijderen dus maar denk ik?
Heb deze gedisabled zodat ik ze kan verwijderen.

Ik heb een eigen verzonnen poort ingesteld. Deze moet ik ook in Winbox gebruiken, want anders kan ik geen verbinding maken.
Is het niet onverstandig om deze hier te posten?
Als ik /ip/services/print doe zie ik deze poort ook staan (TCP).

Dit zijn de interfaces zonder MAC adressen.
Het vreemde is wel dat het aangeeft dat de vlan interface is disabled en dat is deze niet. Als ik in de GUI kijk staat er ook een R van "running" bij. Deze is gekoppeld aan eth1. Zonder deze interface heb ik ook helemaal geen internetverbinding dus er gaat iets mis met de export mbt deze interface.

De enige interface die ik gedisabled heb is de SFP interface (welke helemaal niet in de export staat)

code:

add include=static name=LAN-list
add include=static name=WAN-list
/interface list member
add interface=ether2 list=LAN-list
add interface=ether3 list=LAN-list
add interface=ether4 list=LAN-list
add interface=ether5 list=LAN-list
add interface=Wifi2ghz list=LAN-list
add interface=Wifi5ghz list=LAN-list
add interface=pppoe-client-KPN list=WAN-list
add disabled=yes interface=vlan1.6 list=WAN-list
add interface=back-to-home-vpn list=LAN-list
add interface="Bridge LAN-Wifi" list=LAN-list

De bridge

code:

add comment="Bridge LAN-Wifi" name="Bridge LAN-Wifi"
/interface bridge port
add bridge="Bridge LAN-Wifi" interface=ether2
add bridge="Bridge LAN-Wifi" interface=Wifi2ghz
add bridge="Bridge LAN-Wifi" interface=Wifi5ghz
add bridge="Bridge LAN-Wifi" interface=ether3
add bridge="Bridge LAN-Wifi" interface=ether4
add bridge="Bridge LAN-Wifi" interface=ether5

Acties:

zaterdag 18 april 2026 18:03

Voor de goede orde ook de IPv6 regels.

code:

add action=accept chain=input comment="ACCEPT established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment=defconf:acceptICMPv6 protocol=icmpv6
add action=accept chain=input comment=defconf:acceptUDPtraceroute port=33434-33534 protocol=udp
add action=accept chain=input comment=defconf:acceptDHCPv6-Clientprefixdelegation. dst-port=546 protocol=udp src-address=**::/10
add action=accept chain=input comment="accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="accept all that matches ipsec policy" dst-address-list="" ipsec-policy=in,ipsec
add action=accept chain=input comment=DHCPv6forpublicaddresses dst-address=**::/64 dst-port=546 in-interface=pppoe-client-KPN log-prefix=DHCPv6 protocol=udp
add action=accept chain=input in-interface=pppoe-client-KPN protocol=icmpv6
add action=reject chain=input in-interface=pppoe-client-KPN reject-with=icmp-port-unreachable
add action=drop chain=input comment=defconf:dropeverythingelsenotcomingfromLAN in-interface-list=!LAN-list
add action=drop chain=input comment=defconf:dropinvalid connection-state=invalid
add action=fasttrack-connection chain=forward comment=fasttrack6 connection-state=established,related,untracked
add action=accept chain=forward comment=defconf:acceptestablished,related,untracked connection-state=established,related,untracked
add action=accept chain=forward comment=defconf:acceptHIP protocol=139
add action=accept chain=forward comment="accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward in-interface=pppoe-client-KPN protocol=icmpv6
add action=accept chain=forward connection-state=related in-interface=pppoe-client-KPN
add action=accept chain=forward connection-state=established in-interface=pppoe-client-KPN
add action=drop chain=forward comment=defconf:dropinvalid connection-state=invalid
add action=drop chain=forward comment=defconf:droppacketswithbadsrcipv6 src-address-list=bad_ipv6
add action=drop chain=forward comment=defconf:droppacketswithbaddstipv6 dst-address-list=bad_ipv6
add action=drop chain=forward comment="DROP everythingelsenotcomingfromLAN" in-interface-list=!LAN-list
add action=drop chain=forward comment=defconf:rfc4890drophop-limit1 hop-limit=equal:1 protocol=icmpv6
add action=reject chain=forward in-interface=pppoe-client-KPN reject-with=icmp-no-route

En voor de volledigheid:
De UTP kabel die uit mijn ONT komt gaat in poort eth1.

Acties:

zaterdag 18 april 2026 18:12

winbox poort kan je voor jezelf houden, is hier niet van belang.

regel winbox toegang in de service
/ip service set winbox address=<je lan range of specifieke adressen )

je kan in winbox in je firewall filter rules ook de counters bekijken. als deze na verloop van tijd op 0 blijven kan je er vanuit gaan dat die regel om een of andere reden niet wordt geraakt en mogelijk dan disablen

Acties:

zaterdag 18 april 2026 18:15

Ik heb daar mijn LAN scope staan: 1********/24 (bij available from)

Ik heb een aantal regels die op 0 blijven staan, maar ik heb wel daarstraks een restore van een backup gedaan voordat ik hier de regels had gepost.

Goede tip. Zal dat in de gaten houden.

[ Voor 5% gewijzigd door Mit-46 op 18-04-2026 18:14 ]

Acties:

zaterdag 18 april 2026 18:25

als je winbox service allow-from nu je LAN reeks weergeeft zou je geen verzoeken meer moeten kunnen krijgen op de winbox poorten.

evt. kan je dat zelf ook even testen, bijvoorbeeld hier
https://pentest-tools.com.../port-scanner-online-nmap

mbt de counters van de regels. geef dit een paar dagen de tijd, je wilt zeker weten dat bepaalde regels wel/niet worden geraakt.

[ Voor 19% gewijzigd door ronjon op 18-04-2026 18:16 ]

Acties:

zaterdag 18 april 2026 18:34

Via die site kom ik er niet helemaal uit. Het geeft aan dat alle poorten gesloten zijn, maar als ik https://dw-its.nl/port-scanner/ gebruik en mijn outside IP adres invoer met mijn eigen verzonnen Winbox poort dan geeft het aan dat die poort open is.

Kan het zijn dat er via scans gezocht kan worden naar deze poort voor Winbox?

Acties:

zaterdag 18 april 2026 18:34

Je kunt en moet je icmp ping gewoon aanlaten het is niet schadelijk en een onderdeel van tcp ip en voor ipv6 inderdaad essentieel. Het is echt heel simpel om te kijken of iemand er is zonder ping dus qua security doet het ook niet echt veel.

Misschien overbodig, maar je kunt je chains als volgt zien. Alles wat naar input gaat is je router zelf.
Alles wat door je router heen gaat dus je pc, telefoon etc is forward. Als dus wilt dat iets niet bereikbaar is op je router moet je dat op de input chain blokkeren.

Verder, complimenten voor je volhardendheid! Houd vol het gaat werken!

Acties:

zaterdag 18 april 2026 18:36

Ik heb een regel aangemaakt om de poort te blokkeren en dat is gelukt volgens de port scanner, maar nu heb ik mezelf buitengesloten, want kom zelf Winbox niet meer in via wifi.

Even kijken of het met een kabel nog lukt. Ik heb mijn laatste backups niet gedownload. Niet zo slim

[ Voor 7% gewijzigd door Mit-46 op 18-04-2026 18:35 ]

Acties:

zaterdag 18 april 2026 18:48

Je kunt altijd nog een seriële kabel proberen als je daar een aansluiting voor hebt.
Verder is safe mode je vriend voor dit soort experimenten.
Wat ik ook vaak doe is een management port aanmaken op een afwijkend netwerk een firewall regel die verkeer toestaat vanaf die poort.

Acties:

zaterdag 18 april 2026 19:50

Ha! Dit is wel ironisch. Ik wilde graag inlogpogingen in Winbox voorkomen en nu kan ik zelf niet eens meer inloggen. Heb ik in ieder geval bereikt wat ik wilde, maar het is nu wel een beetje overdreven.

Ik ga even een boodschap doen en een frisse neus halen. Had niet helemaal gepland vandaag zo met de router in de weer te gaan. Dacht juist dat ik het wel goed had.

Volgens mij zit ik wel op het goede spoor met die poort die schijnbaar vanaf het internet te scannen is/was.
Ik had wel poort scans gedaan, maar dan weer niet specifiek op de custom Winbox poort.

Ga straks kijken of ik er in weet te komen en als het moet beginnen we (deels) overnieuw. Heb nog wel een oudere backup op mijn laptop, maar ik hoop dat bij een hard reset de backups nog in files staan. En anders staan al mijn regels hier op Tweakers aangezien ik deze hier vandaag gepost heb dus dat scheelt

Ik heb het idee dat ik ervoor moet zorgen dat die poort dicht staat voor WAN, maar wel open voor LAN en dat ik dan mijn doel heb bereikt. Althans, dat hoop ik.

[ Voor 12% gewijzigd door Mit-46 op 18-04-2026 18:52 ]

Acties:

zaterdag 18 april 2026 21:23

precies.
je winbox poort moet alleen open zijn voor LAN.

volgende keer als je in winbox aan de slag gaat, direct safe mode aan. het grote voordeel is dat wanneer je jezelf buitensluit, zal safemode detecteren dat je connectie weg is en alle wijzigingen die je hebt gemaakt terugdraaien.

mocht je je wijzigingen tussentijds willen opslaan dan kan je safemode be-eindigen om je wijzigingen permanent te maken en daarna safemode weer aanzetten (rinse-repeat )

Acties:

zaterdag 18 april 2026 21:37

Het is gelukt. Dank ook weer voor de safe mode tip. Die kende ik nog niet. Beter laat dan nooit, maar ik heb beseft dat die mij heel veel keren resetten had kunnen besparen.

Super handig!

Nu heb ik de poort weten te blokkeren door een input, op de pppoe interface, src, desbetreffende Winbox poort, drop.

Het enige wat ik nu niet begrijp is dat dit alleen werkt wanneer ik deze regel boven de laatste input, accept regel plaats. Dat is onderstaande regel.

;;; LAN=list -ACCEPT
chain=input action=accept in-interface-list=LAN-list log=no log-prefix=""

Ik zie nog activiteit op deze rule dus ik ga er vanuit dat ik deze hiermee niet om zeep heb geholpen.
De tip mbt de activiteit is ook erg nuttig. Zal de boel netjes opruimen.

Er waren vanavond weer een aantal denied winbox/dude connect from 85.10.157.92 meldingen (dit is niet mijn IP adres, maar waarmee geprobeerd wordt om in te loggen)

De laatste was om 21:09 uur en om 21:10 heb ik de regel zo gekregen dat ik via een port scan zie dat die geblokkeerd is. Sindsdien geen melding meer en het zijn er toch 24 geweest vanaf (toevallig) 20.24 uur. Dat is ongeveer het moment waarop ik de router had gereset en een backup terug had gezet zodat ik zelf weer Winbox in kon.

Fingers crossed dat dit de truc is.

Iedereen weer bedankt voor de wijze lessen vandaag! Het doel hopelijk bereikt en anders sowieso weer een hoop geleerd.

[ Voor 9% gewijzigd door Mit-46 op 18-04-2026 21:29 ]

Acties:

babbelbox

Je pppoe is vast geen lid van WAN interface list
Nevermind, staat al in je eerder bericht, dat is op zich goed.
Ik ben zelf toch niet zo'n fan van die globale lists.
Ik heb alleen firewall address lists die diverse gelijke type systemen bevatten. Verder accept ik op IP of poort.
En uiteindelijk drop, zonder enige voorwaarde.

[ Voor 75% gewijzigd door babbelbox op 18-04-2026 21:44 ]

zaterdag 18 april 2026 21:59

Acties:

zondag 19 april 2026 07:44

Ik denk dat ik het beter moeten leren te begrijpen voordat ik het zo kan toepassen. Ben nog nooit zo diep in een router, laat staan firewall regels, gedoken als afgelopen maand.

Ik ben niet uitgeleerd en nog gemotiveerd.

PS:
Vooralsnog geen denied meldingen!

Acties:

zondag 19 april 2026 12:33

de "mikrotik" manier om winbox connecties van buitenaf te blokken is via /ip/services
https://help.mikrotik.com.../pages/103841820/Services

als het goed is heb je nu je interne lan address toegevoegd aan de winbox service Available-From.
enige wat ik me kan bedenken is er mogelijk op ipv6 nog connectie geprobeert wordt te maken.

je zou kunnen proberen om je interne ipv6 LAN range ook eens toe te voegen aan de winbox service.

ps. je oplossing werkt, en daarmee is het probleem van de remote connecties opgelost, dus je kan het zo laten. ikzelf doe het het liefst op de services manier, scheelt ook weer 2 regels in je firewall )

Acties:

zondag 19 april 2026 20:21

Heel vreemd, maar gisteravond ben ik gaan slapen terwijl alles normaal leek te werken. Ik had de Winbox poort via de IPv4 firewall had dichtgezet en ben daarna nog in Winbox bezig geweest.
Vanochtend kon ik alleen "opeens" weer niet inloggen.

Ik heb gister de safemode ook gebruikt dus ik begrijp het niet helemaal, want totdat ik ging slapen werkte het nog.
Verder werkte vanochtend ook opeens niet alle websites meer en viel de verbinding deels weg. Leek weer op vaag DNS gedrag. Heb gister ook veel zitten wijzigen, ook weer aan de DNS instellingen terwijl deze goed werkte daarvoor.
Ik ben dus 2 stapjes terug gegaan met een backup. Terug naar gisterochtend (eergisteravond) waarmee ik de dag begon, want toen werkte alles nog goed. Nu ben ik weer alles aan het aanpassen met de kennis die ik gister heb opgedaan

Iets super interessants wat ik vandaag heb opgemerkt is dat door een poortscan de melding, "denied winbox/dude connect from 85.10.157.92", verschijnt

Ik zat zelf te scannen en toen viel mij op dat de meldingen erbij kwamen wanneer de poort open staat vanaf het internet.
85.10.157.92" is het IP adres van: https://dw-its.nl/port-scanner/ waarmee ik de Winbox poort scan.

Het zijn dus geen aanmeldpogingen in Winbox zelf, maar alleen poort scans. Super verwarrend en het heeft mij (ons) lekker bezig gehouden!

Dit verklaart ook waarom ik gister zo bizar veel meldingen had, want ik was er hevig op los aan het scannen.

Ik ben er alleen nog niet achter hoe ik die poort nu kan blokkeren vanaf het internet, want elke keer dat het mij lukt kan ik vervolgens zelf ook niet meer inloggen.

Straks nog eens kijken of ik het voor elkaar krijg.
Ik heb nu een Input, Drop, dst port ****, (!) interface=LAN bridge.

De poort staat weer dicht van buitenaf dus nu maar hopen dat ik straks niet opeens weer "locked out" ben. Safe mode staat dus het zou niet moeten.

Wel heb ik nu ook voor de goede orde de IPv6 link local adres scope toegevoegd aan /IP/services/Winbox.

**edit:
Heb een regel aangemaakt.

[ Voor 15% gewijzigd door Mit-46 op 19-04-2026 13:42 ]

Acties:

zondag 19 april 2026 20:28

hoe gebruik je safe mode?

als ik je vorige bericht lees, lijkt het of je safe mode aan laat staan, ook nadat je klaar bent met je wijzigingen.

wanneer je in safe mode wijzigingen doorvoert, en je bent klaar en weet zeker dat ze werken, moet je safe mode weer uitzetten via de knop.

als je de winbox applicatie sluit, (zonder safe mode te de-activeren) wordt dit gezien als een connectie error en worden je wijzigingen terug gedraait.

voor wat betreft de logs, als je heel zeker weet dat je firewall goed werkt, kan je in /system/logging/rules de topics account en firewall disablen of verwijderen. deze zouden voor logs zoals winbox/the dude kunnen zorgen.
(ik heb het net even zelf getest, maar of ik deze logging rules nu wel of niet aanzet, ik krijg bij mij geen log berichten over mogelijke connectie verzoeken. ik test met nmap vanaf een remote systeem )

Acties:

zondag 19 april 2026 22:02

je kan je hele config ook eens door chatgpt of een andere AI laten controleren met verbeter suggesties.
houdt er wel rekening mee dat niet alle suggesties de juiste zijn, dus zelf goed nadenken / uitzoeken (bijv. mikrotik forum) is wel aan te raden.

/export file=<naam>
dan in files het bestand downloaden
alle mogelijk interessante info zoals wachtwoorden (als het goed is staan deze er al niet in), eigen ip adres, vpn wachtwoorden of keys, etc vervangen door xxxxxx of zoiets en dan uploaden in een ai model

dit kan je trouwens ook doen voor je firewall
/ip/firewall export

[ Voor 6% gewijzigd door ronjon op 19-04-2026 20:29 ]

Acties: