Mikrotik ai rsc - please check

Hello to everyone.

I used the Mikrotik AI support to create a rsc. for the Hap Ax³.

I would really appreciate if someone could take a look at it.

Is this rsc. safe to use?

Thank you in advance.

RSC STARTS HERE:



# ZERO TRUST PRO++ FINAL V12.3 SAFE - Korrigiert (vlan-filtering=no)
/tool mac-server set allowed-interface-list=all
/tool mac-server mac-winbox set allowed-interface-list=all
/ip firewall filter add chain=input action=accept comment="TEMP-ACCESS"
# =========================
# BRIDGE (SAFE + WiFi Fix)
# =========================
/interface bridge
add name=br-lan vlan-filtering=no protocol-mode=rstp igmp-snooping=yes

/interface bridge port
add bridge=br-lan interface=ether2 pvid=20 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged
add bridge=br-lan interface=ether3 pvid=23 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged
add bridge=br-lan interface=ether4 pvid=22 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged
add bridge=br-lan interface=ether5 pvid=10 ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged
add bridge=br-lan interface=wifi1 ingress-filtering=no frame-types=admit-all
add bridge=br-lan interface=wifi2 ingress-filtering=no frame-types=admit-all

/interface bridge vlan
add bridge=br-lan vlan-ids=10 tagged=br-lan,wifi1,wifi2 untagged=ether5
add bridge=br-lan vlan-ids=20 tagged=br-lan,wifi1,wifi2 untagged=ether2
add bridge=br-lan vlan-ids=21 tagged=br-lan,wifi1,wifi2
add bridge=br-lan vlan-ids=22 tagged=br-lan,wifi1,wifi2 untagged=ether4
add bridge=br-lan vlan-ids=23 tagged=br-lan,wifi1,wifi2 untagged=ether3
add bridge=br-lan vlan-ids=33 tagged=br-lan,wifi1,wifi2
add bridge=br-lan vlan-ids=34 tagged=br-lan,wifi1,wifi2

# =========================
# VLAN INTERFACES
# =========================
/interface vlan
add name=vlan10-mgmt    interface=br-lan vlan-id=10
add name=vlan20-trusted interface=br-lan vlan-id=20
add name=vlan21-mobile  interface=br-lan vlan-id=21
add name=vlan22-tv      interface=br-lan vlan-id=22
add name=vlan23-gaming  interface=br-lan vlan-id=23
add name=vlan33-iot     interface=br-lan vlan-id=33
add name=vlan34-guest   interface=br-lan vlan-id=34

# =========================
# IP ADDRESSES
# =========================
/ip address
add address=192.168.10.1/24 interface=vlan10-mgmt
add address=192.168.20.1/24 interface=vlan20-trusted
add address=192.168.21.1/24 interface=vlan21-mobile
add address=192.168.22.1/24 interface=vlan22-tv
add address=192.168.23.1/24 interface=vlan23-gaming
add address=192.168.33.1/24 interface=vlan33-iot
add address=192.168.34.1/24 interface=vlan34-guest

# =========================
# DHCP
# =========================
/ip pool
add name=pool10 ranges=192.168.10.100-192.168.10.254
add name=pool20 ranges=192.168.20.100-192.168.20.254
add name=pool21 ranges=192.168.21.100-192.168.21.254
add name=pool22 ranges=192.168.22.100-192.168.22.254
add name=pool23 ranges=192.168.23.100-192.168.23.254
add name=pool33 ranges=192.168.33.100-192.168.33.254
add name=pool34 ranges=192.168.34.100-192.168.34.254

/ip dhcp-server
add name=dhcp10 interface=vlan10-mgmt address-pool=pool10 disabled=no
add name=dhcp20 interface=vlan20-trusted address-pool=pool20 disabled=no
add name=dhcp21 interface=vlan21-mobile address-pool=pool21 disabled=no
add name=dhcp22 interface=vlan22-tv address-pool=pool22 disabled=no
add name=dhcp23 interface=vlan23-gaming address-pool=pool23 disabled=no
add name=dhcp33 interface=vlan33-iot address-pool=pool33 disabled=no
add name=dhcp34 interface=vlan34-guest address-pool=pool34 disabled=no

/ip dhcp-server network
add address=192.168.10.0/24 gateway=192.168.10.1 dns-server=192.168.10.1
add address=192.168.20.0/24 gateway=192.168.20.1 dns-server=192.168.20.1
add address=192.168.21.0/24 gateway=192.168.21.1 dns-server=192.168.21.1
add address=192.168.22.0/24 gateway=192.168.22.1 dns-server=192.168.22.1
add address=192.168.23.0/24 gateway=192.168.23.1 dns-server=192.168.23.1
add address=192.168.33.0/24 gateway=192.168.33.1 dns-server=192.168.33.1
add address=192.168.34.0/24 gateway=192.168.34.1 dns-server=192.168.34.1

/ip dhcp-server lease
add address=192.168.23.10 mac-address=AA:AA:AA:AA:AA:AA comment="XBOX-ETH"
add address=192.168.23.11 mac-address=BB:BB:BB:BB:BB:BB comment="XBOX-WIFI"

# =========================
# WAN + NAT
# =========================
/interface pppoe-client
add name=pppoe-out1 interface=ether1 user="USER1" password="PASSWORD1" add-default-route=yes use-peer-dns=no max-mtu=1492 max-mru=1492

/ip firewall nat
add chain=srcnat out-interface=pppoe-out1 action=masquerade

# Xbox Port Forwards
add chain=dstnat in-interface=pppoe-out1 protocol=udp dst-port=88 action=dst-nat to-addresses=192.168.23.10
add chain=dstnat in-interface=pppoe-out1 protocol=tcp dst-port=3074 action=dst-nat to-addresses=192.168.23.10
add chain=dstnat in-interface=pppoe-out1 protocol=udp dst-port=3074 action=dst-nat to-addresses=192.168.23.10
add chain=dstnat in-interface=pppoe-out1 protocol=udp dst-port=500 action=dst-nat to-addresses=192.168.23.10
add chain=dstnat in-interface=pppoe-out1 protocol=udp dst-port=3544 action=dst-nat to-addresses=192.168.23.10
add chain=dstnat in-interface=pppoe-out1 protocol=udp dst-port=4500 action=dst-nat to-addresses=192.168.23.10

# =========================
# FIREWALL (Winbox nur 8291)
# =========================
/ip firewall filter

# Input Chain
add chain=input src-address=192.168.10.0/24 protocol=udp dst-port=53 action=accept
add chain=input src-address=192.168.10.0/24 protocol=tcp dst-port=53 action=accept
add chain=input src-address=192.168.20.0/24 protocol=udp dst-port=53 action=accept
add chain=input src-address=192.168.20.0/24 protocol=tcp dst-port=53 action=accept
add chain=input connection-state=established,related action=accept
add chain=input connection-state=invalid action=drop

# Nur Winbox erlaubt
add chain=input in-interface=vlan10-mgmt src-address=192.168.10.0/24 protocol=tcp dst-port=8291 action=accept

add chain=input protocol=icmp action=accept
add chain=input in-interface=pppoe-out1 action=log log-prefix="WAN_DROP" limit=10,5
add chain=input in-interface=pppoe-out1 action=drop
add chain=input action=drop

# Forward Chain (Rest unverändert)
add chain=forward connection-state=established,related action=accept
add chain=forward connection-state=invalid action=drop

add chain=forward in-interface=pppoe-out1 dst-address=192.168.23.10 protocol=udp dst-port=88,3074,500,3544,4500 action=accept
add chain=forward in-interface=pppoe-out1 dst-address=192.168.23.10 protocol=tcp dst-port=3074 action=accept

add chain=forward src-address=192.168.20.0/24 out-interface=pppoe-out1 action=accept
add chain=forward src-address=192.168.21.0/24 out-interface=pppoe-out1 action=accept
add chain=forward src-address=192.168.22.0/24 out-interface=pppoe-out1 action=accept
add chain=forward src-address=192.168.23.0/24 out-interface=pppoe-out1 action=accept
add chain=forward src-address=192.168.34.0/24 out-interface=pppoe-out1 action=accept

add chain=forward src-address=192.168.10.0/24 protocol=udp dst-port=53 action=accept
add chain=forward src-address=192.168.10.0/24 protocol=tcp dst-port=53 action=accept
add chain=forward src-address=192.168.10.0/24 protocol=udp dst-port=123 action=accept
add chain=forward src-address=192.168.10.0/24 protocol=tcp dst-port=443 action=accept
add chain=forward src-address=192.168.10.0/24 out-interface=pppoe-out1 action=drop

add chain=forward src-address=192.168.33.0/24 protocol=udp dst-port=53 dst-address=192.168.33.1 action=accept
add chain=forward src-address=192.168.33.0/24 protocol=tcp dst-port=53 dst-address=192.168.33.1 action=accept
add chain=forward src-address=192.168.33.0/24 protocol=tcp dst-port=443 out-interface=pppoe-out1 action=accept
add chain=forward src-address=192.168.33.0/24 out-interface=pppoe-out1 action=drop

add chain=forward src-address=192.168.0.0/16 dst-address=192.168.0.0/16 action=drop
add chain=forward action=drop

# =========================
# MANGLE + SQM + WIFI + SERVICES
# =========================
/ip firewall mangle
add chain=prerouting in-interface=pppoe-out1 dst-address=192.168.23.0/24 action=mark-packet new-packet-mark=gaming-down passthrough=no
add chain=prerouting in-interface=pppoe-out1 dst-address=192.168.21.0/24 action=mark-packet new-packet-mark=mobile-down passthrough=no
add chain=prerouting in-interface=pppoe-out1 action=mark-packet new-packet-mark=default-down passthrough=no

add chain=postrouting out-interface=pppoe-out1 src-address=192.168.23.0/24 action=mark-packet new-packet-mark=gaming-up passthrough=no
add chain=postrouting out-interface=pppoe-out1 src-address=192.168.21.0/24 action=mark-packet new-packet-mark=mobile-up passthrough=no
add chain=postrouting out-interface=pppoe-out1 action=mark-packet new-packet-mark=default-up passthrough=no

add chain=forward out-interface=pppoe-out1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1360

/queue type
add name=fq-codel kind=fq-codel

/queue tree
add name=SQM-UP parent=pppoe-out1 max-limit=28M
add name=SQM-DOWN parent=global max-limit=180M
add name=GAMING-UP parent=SQM-UP packet-mark=gaming-up queue=fq-codel priority=1 limit-at=28M max-limit=28M
add name=MOBILE-UP parent=SQM-UP packet-mark=mobile-up queue=fq-codel priority=6
add name=DEFAULT-UP parent=SQM-UP packet-mark=default-up queue=fq-codel priority=8
add name=GAMING-DOWN parent=SQM-DOWN packet-mark=gaming-down queue=fq-codel priority=1 limit-at=180M max-limit=180M
add name=MOBILE-DOWN parent=SQM-DOWN packet-mark=mobile-down queue=fq-codel priority=6
add name=DEFAULT-DOWN parent=SQM-DOWN packet-mark=default-down queue=fq-codel priority=8

/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
set ssh address=192.168.10.0/24
set winbox address=192.168.10.0/24
set www-ssl address=192.168.10.0/24

# WiFi Konfiguration (unverändert)
#[Rest des WiFi-Abschnitts wie zuvor – identisch mit der letzten Version]

/interface wifi security
add name=sec-trusted authentication-types=wpa3-psk passphrase="TRUSTED_STRONG_PASSWORD"
add name=sec-mobile authentication-types=wpa3-psk passphrase="MOBILE_DEVICES_KEY"
add name=sec-tv authentication-types=wpa2-psk,wpa3-psk passphrase="TV_ISOLATED_KEY"
add name=sec-gaming authentication-types=wpa3-psk passphrase="GAMING_LOW_LATENCY_KEY"
add name=sec-iot authentication-types=wpa2-psk passphrase="IOT_RESTRICTED_KEY"
add name=sec-guest authentication-types=wpa2-psk passphrase="GUEST_ROTATING_KEY"
add name=sec-mgmt authentication-types=wpa3-psk passphrase="VERY_STRONG_MGMT_PASSWORD" management-protection=allowed

/interface wifi datapath
add name=dp-trusted bridge=br-lan vlan-mode=use-tag vlan-id=20
add name=dp-mobile bridge=br-lan vlan-mode=use-tag vlan-id=21
add name=dp-tv bridge=br-lan vlan-mode=use-tag vlan-id=22
add name=dp-gaming bridge=br-lan vlan-mode=use-tag vlan-id=23
add name=dp-iot bridge=br-lan vlan-mode=use-tag vlan-id=33
add name=dp-guest bridge=br-lan vlan-mode=use-tag vlan-id=34
add name=dp-mgmt bridge=br-lan vlan-mode=use-tag vlan-id=10

/interface wifi configuration
add name=cfg-trusted ssid=Trusted-WiFi security=sec-trusted datapath=dp-trusted mode=ap country=Germany client-isolation=yes
add name=cfg-mobile ssid=Mobile-WiFi security=sec-mobile datapath=dp-mobile mode=ap country=Germany client-isolation=yes
add name=cfg-tv ssid=TV-WiFi security=sec-tv datapath=dp-tv mode=ap country=Germany client-isolation=yes
add name=cfg-gaming ssid=Gaming-WiFi security=sec-gaming datapath=dp-gaming mode=ap country=Germany client-isolation=yes
add name=cfg-iot ssid=IoT-WiFi security=sec-iot datapath=dp-iot mode=ap country=Germany client-isolation=yes
add name=cfg-guest ssid=Guest-WiFi security=sec-guest datapath=dp-guest mode=ap country=Germany client-isolation=yes
add name=cfg-mgmt ssid=Mgmt-WiFi security=sec-mgmt datapath=dp-mgmt mode=ap country=Germany client-isolation=yes ssid-hidden=yes

/interface wifi
set [find default-name=wifi1] configuration=cfg-trusted
set [find default-name=wifi2] configuration=cfg-trusted

add master-interface=wifi1 name=wifi1-iot configuration=cfg-iot
add master-interface=wifi1 name=wifi1-guest configuration=cfg-guest
add master-interface=wifi1 name=wifi1-gaming configuration=cfg-gaming
add master-interface=wifi1 name=wifi1-mobile configuration=cfg-mobile
add master-interface=wifi1 name=wifi1-mgmt configuration=cfg-mgmt

add master-interface=wifi2 name=wifi2-iot configuration=cfg-iot
add master-interface=wifi2 name=wifi2-guest configuration=cfg-guest
add master-interface=wifi2 name=wifi2-gaming configuration=cfg-gaming
add master-interface=wifi2 name=wifi2-mobile configuration=cfg-mobile
add master-interface=wifi2 name=wifi2-mgmt configuration=cfg-mgmt

/interface wifi access-list
add interface=wifi1-mgmt mac-address=XX:XX:XX:XX:XX:XX action=accept
add interface=wifi2-mgmt mac-address=XX:XX:XX:XX:XX:XX action=accept
add interface=wifi1-mgmt action=reject
add interface=wifi2-mgmt action=reject

/ip dns
set allow-remote-requests=yes servers=1.1.1.1,1.0.0.1

/ipv6 settings
set disable-ipv6=yes

As you can see the final rsc is the product of many iterations. It was quite a hustle and took me many hours to complete. The chatbot itself says, the rsc is correct and will work, besides always insisting to change the SQM to parent=global-in. That is obvioulsy wrong. Also be aware, that the original rsc files uses correct # structure for comments.

Well, you should be aware that - had you posted the configuration using the appropriate </> button - the board parser would have interpreted the # correctly.

Looks like VLAN filtering is not active on the bridge.

I prefer to work with address lists on the firewall instead of per network.

Thank you, for the hint. I edited the original post.

The VLAN filtering is deactivated on purpose, to ensure having access to the router in case something is wrong with the config.
The final step would be /interface bridge set br-lan vlan-filtering=yes

Good :slightly_smiling_face:, now it is much more readable.
You can even better it if you add "RouterOS" after the three bacticks, i.e. from:
'''
your code
'''
to:
'''RouterOS
your code
'''
the board software sometimes recognizes the RouterOS syntax and the contents is parsed correctly (with colour enhancement) sometimes it need to be "forced".

Looky here:

Now, as a user forum,
we've gone from helping users to becoming Artificial Deficiency Correctors.

I refuse to correct these things,
also because they aren't the product of a human being's intellect,
who understandably needs help when possible,
who needs to be made to understand where they're going wrong, especially if they've taken the time to study how things work.

Being treated like free proofreaders?
GTH.

I respect your point of view. Please allow me to give you some thoughts of mine.

The rsc is the result of a ( very long) dialog, trying to overcome the initial barrier of router os complexity.

I really enjoyed the process, despite having a lot of frustrating moments, i can say i gained some knowledge.

Nonetheless i'm aware that these llm's are flawed tools and the result may be insufficent.

I'm not a professional, never will be. I 'm just an amateur trying to set up his home network, in his rare spare time.

I tried to create a foundation and now i'm looking for advice by people that know what they are talking about.

I would really like to have your insides on the rsc.

Yep, I also often have long conversations with my cat, and while I usually learn a lot about mice catching and long sleeping, I don't trust her when she tries to convince me that it would be much better for me to leave a huge heap of dry cat food near the entrance, as this way I would avoid all the trouble of giving a little to her a couple times a day.

The issue with these Artificial Inteligences is that they are programmed to be:

  1. competent (but they sometimes are, sometimes not)
  2. authoritative (but they are only seemingly so)
  3. obliging (and they are even too much so)

The configuration proposed is - in large part - overcomplicated and in some other parts going well over my head :astonished_face:, personally I am modest (not everywhere, in spots :wink:) and I would start with the default firewall and the conventions LAN/WAN used normally, as opposed to inventing a completely new firewall set of filter rules.

Same goes for the wifi settings.
Cannot say if right or wrong, all I can say is that I have never seen such a complicated setup (7 SSIDs?).

All I can tell you is that this (by itself):

/ipv6 settings
set disable-ipv6=yes

is not particularly safe, see point #33 here:
GP & CSA (Good Practice and Common Sense Advice) for Mikrotik devices

Wilson, why my VLANs cast me away? Whyyyy?

Thank you for your opinion.

It is the approach that's the problem, not AI. Your router started with a perfectly good, well test config, that should be safe. It does not have VLANs, and you want VLAN for some reason. So if you allow an "raw" AI without an SKILLs/instruction/prompts/MCPs to "guide" it, it has to do a shit ton of guessing/probability at each line of new config. TL;DR: IDK your goals with VLANs but AFAIK your config lacks a good firewall, at the VERY least.

So if you provide it the stock default configuration (from export), and at miniminum prompt to ✨ Steering AI to use new manual.mikrotik.com you'll likely end up at much better starting place. Perhaps start by asking how to get back to default-configuration as the first step.

Now that still may not help that much unless your prompt more than "... I want to VLAN my network .... Like the "forum rules" suggestion: describe your problem not desired configuration. This applies equally to AI LLMs as does this forum.

And I use the free GPT, it answers your own question "Is this safe to use?"

prompt to free ChatGPT

ou are helping with MikroTik RouterOS. Assume RouterOS v7 unless I say otherwise.

Your training data is unreliable for RouterOS: it is dominated by the old
wiki.mikrotik.com (mostly v6) and the retired Confluence help site, so you tend
to mix v6 and v7 syntax and invent commands or properties. Do not trust your
memory for exact syntax.

The current authoritative source is MikroTik's new manual, which publishes a
machine-readable copy of every page:

For every RouterOS question:

  1. Fetch /llms.txt and pick the relevant page(s).
  2. Fetch the ".md" version of those page(s) for the actual content.
  3. For exact command paths, property names, argument types and enum values,
    check the CLI Reference and match what it defines — do not invent flags.
  4. Cite the page(s) you used.
  5. If you could not fetch the docs, say so and answer from memory only with a
    warning — never present unverified syntax as fact.Is this rsc. safe to use?

Thank you in advance.

RSC STARTS HERE:

config copied from OP and pasted to prompt

free ChatGPT answer

Short answer: No, I would not consider this safe to import as-is on a production RouterOS v7 device.

There are several categories of problems:

  1. Likely lockout / management access issues
  2. VLAN architecture inconsistencies
  3. Firewall logic bugs
  4. WiFi VLAN implementation concerns
  5. Queueing/SQM issues
  6. A few syntax/version assumptions that should be verified

Per your instructions, I checked the current MikroTik documentation rather than relying on memory. The most important reference here is the Bridge VLAN Filtering documentation. It explicitly states that bridge VLAN settings such as pvid, ingress-filtering, frame-types, and the /interface bridge vlan table only become meaningful when vlan-filtering=yes. With vlan-filtering=no, the bridge ignores VLAN tags and does not perform VLAN-aware forwarding. (manual.mikrotik.com)


1. Biggest issue: VLAN configuration doesn't actually enforce VLANs

You have:

/interface bridge
add name=br-lan vlan-filtering=no

but then hundreds of lines of:

/ interface bridge port
pvid=...
ingress-filtering=yes
frame-types=...

and

/ interface bridge vlan
add vlan-ids=...

The RouterOS manual is very clear:

pvid, ingress-filtering, and bridge VLAN table processing only take effect when vlan-filtering=yes. (manual.mikrotik.com)

So with:

vlan-filtering=no

your bridge is essentially operating as a shared L2 domain.

That means the configuration is internally contradictory:

  • bridge VLAN table exists
  • access ports have PVIDs
  • WiFi datapaths tag VLANs
  • VLAN interfaces exist on the bridge

but the bridge itself is not VLAN-aware.

I strongly suspect whoever wrote this was trying to avoid lockout and forgot the final:

/ interface bridge
set br-lan vlan-filtering=yes

step that MikroTik recommends performing only after the VLAN table is complete. (manual.mikrotik.com)


2. TEMP-ACCESS firewall rule never removed

At the top:

/ip firewall filter add chain=input action=accept comment="TEMP-ACCESS"

This is extremely dangerous.

Because firewall rules are processed in order, this becomes:

accept everything to router

before any of the later input-chain restrictions.

So until manually removed:

  • Winbox exposed
  • SSH exposed
  • DNS exposed
  • every service exposed

from every interface.

If this script is imported and something fails before cleanup, you've accidentally bypassed the entire "Zero Trust" firewall.


3. MAC services opened everywhere

You explicitly do:

/tool mac-server set allowed-interface-list=all
/tool mac-server mac-winbox set allowed-interface-list=all

This is the opposite of a hardened router.

Normally I'd expect:

allowed-interface-list=LAN

or a management VLAN only.

With this config:

  • MAC Winbox available everywhere
  • MAC Telnet available everywhere

including guest/iot/trusted segments.

I would never leave that in a finished deployment.


4. DNS rules don't do what author thinks

You have:

add chain=forward src-address=192.168.33.0/24 protocol=udp dst-port=53 dst-address=192.168.33.1 action=accept

and similar.

But traffic destined to:

192.168.33.1

(the router)

goes through:

input

not

forward

chain.

So these rules are ineffective.

The actual DNS permissions are coming from:

/ip dns
set allow-remote-requests=yes

plus whatever input-chain rules happen to permit reaching the router.


5. IoT VLAN may not resolve DNS at all

Input chain only allows DNS from:

192.168.10.0/24
192.168.20.0/24

I don't see corresponding allows for:

192.168.21.0/24
192.168.22.0/24
192.168.23.0/24
192.168.33.0/24
192.168.34.0/24

Yet DHCP hands out:

dns-server = router IP

for every VLAN.

Example:

192.168.33.1

is distributed as DNS server.

But input chain appears to drop those DNS requests.

So IoT, guest, gaming, mobile, TV likely lose DNS entirely.

This is one of the first things I'd test.


6. Guest and IoT isolation is incomplete

You have:

add chain=forward src-address=192.168.0.0/16 dst-address=192.168.0.0/16 action=drop

near the bottom.

That does block inter-VLAN routing.

Good.

However it also means:

  • no local DNS server on another subnet
  • no NTP server on another subnet
  • no management station access
  • no Chromecast/AirPlay style cross-VLAN operation

Maybe intentional, maybe not.

Just be aware it's a blunt instrument.


7. Queue tree probably not doing what author expects

This stood out:

add name=SQM-DOWN parent=global max-limit=180M

Modern RouterOS queue-tree designs are usually interface-based.

The old global parent behavior has changed over RouterOS releases and is frequently misunderstood.

I'd want to verify against current queue-tree documentation before trusting the shaping behavior.

I would not assume this delivers true CAKE/FQ-CoDel style SQM.


8. WiFi VLAN design looks suspicious

You bridge:

wifi1
wifi2

directly into the bridge.

Then create datapaths:

vlan-mode=use-tag
vlan-id=20
...

Then create virtual APs.

This might work depending on the exact wifi package and hardware.

But because the bridge itself is configured:

vlan-filtering=no

the entire tagged WiFi architecture becomes questionable.

The current MikroTik VLAN examples generally assume bridge VLAN filtering is the active VLAN enforcement mechanism. (manual.mikrotik.com)


9. Management WiFi access-list is not sufficient protection

You have:

/interface wifi access-list
add interface=wifi1-mgmt mac-address=...
add interface=wifi2-mgmt mac-address=...
add interface=wifi1-mgmt action=reject
add interface=wifi2-mgmt action=reject

MAC filtering is easy to bypass once an authorized MAC is observed.

It is fine as an additional control.

It should not be considered a meaningful security boundary.


10. PPPoE credentials in plain text

Not a RouterOS problem, but if this script gets shared:

user="USER1"
password="PASSWORD1"

is an obvious risk.


My overall assessment

If someone handed me this for review, I'd classify it as:

Area Assessment
Router lockout risk Medium
VLAN correctness Poor
Firewall correctness Mixed
WAN exposure High until TEMP-ACCESS removed
WiFi design Needs validation
Inter-VLAN isolation Mostly works
Production readiness No

The single biggest red flag is that the entire design is built around:

/ interface bridge vlan
...

yet the bridge remains:

vlan-filtering=no

According to MikroTik's current documentation, that means most of the VLAN enforcement configuration is not actually active. (manual.mikrotik.com)

If you'd like, I can go through it line-by-line as a RouterOS v7 config review and identify which parts are actually valid, which are ineffective, and which would likely fail on an hAP ax² specifically.

And, out of curiosity, why you don't §@¢#ing verify It, are you a lazy AI?

@Amm0
Now, you are being unfair, two thirds of the reply are due to vlan-filtering=no, while OP explicitly stated how It was temporary.

@jaclaz, I was highlighting the same point - iterate with AI before dumping some random config that does not work. And, "My reply" is strong ... I did one prompt, and copied the result... as an example for OP. Asking more questions of the AI should have the next move here.

It the free web-based ChatGPT. And it was answering the question "Is this safe?", so keep that in mind. I didn't put GPT 5.5 or Opus/Fabel on this particular task.

Garbage in. Garbage out.

Hi Amm0,

thank you for your comment and your input.

Your assumptions on how this rsc was created are incorrect.

The llm i used is https://mikrotik.com/support

The goal is a config that is close to a zero trust config.

The final import should be done on no default config.

Just a few comments on what you wrote:

That is on purpose. Activation of vlan-filtering is one of the last steps, once the import of the rsc is done.

This is rule is temporary to ensure access to the router until the config is successfully running. It will be removed afterwards /ip firewall filter remove [find comment="TEMP-ACCESS"]

Same as above. Will be removed once everything is running.

The idea was to restrict dns for guest network.

So what you say is, that does not work?

That maybe a real issue. Thank you for pointing it out.

Yes, it is on purpose to max out isolation.

This where the llm struggled the most. It constantly insisted to use global-in as parent refering to new router os version. I m using router os 7.23 and global-in is not available as an option.

wifi-qcom is used, so that seems to be the fitting syntax

I m aware of mac spoofing. I decided to make winbox available from sperate managment wifi and add an extra layer of security by limiting access to a specific mac adress. I know this is contrary to zero trust, but it's a convenience trade off i 'm willing to take.

These are dummy credentials. Same goes for wifi passwords.

I would really appreciate, if you could do that! Be aware i'm using an Hap ax ³

Thank you for putting your time and effort into helping me.

@ normis would you mind, sharing your point of view on this too?!

@2HopLa,

Amm0 has extensive practical experience, and I would regard him as an expert in both LLMs and ROS. So if the question concerns work in either of those areas, Amm0 is the right person to ask, IMO.

Hi Larsa,

thank you for you comment. It was not my intention to put Amm0 into question. In fact i m really grateful that he offered his help.

The reason i asked for normis opinion is, that the origin of the rsc is based on Mikrotiks own LLM chatbot.