Hey everyone. I manage FTTH infrastructure at an ISP and got tired of rewriting the same categories of configs (PPPoE servers, VLAN setups, firewall hardening, RADIUS client config) every time with small variations.
Put together a tool called MikroTik Config Generator. You describe what you need in plain text; it outputs a complete RouterOS v7 script targeting current best practices: management access restricted to defined subnets, unused services disabled, invalid connections dropped by default.
It also has a review mode. Paste an existing config export, and it flags security or performance issues with corrected commands.
Still early. If any of you test it on real configs, I would genuinely appreciate feedback, especially anywhere it gets RouterOS syntax wrong or misses a hardening step you would normally apply manually.
FYI, You should be aware that +92 is in most NA national ISP + Cell Phone networks blocked or identified as a scam or spam area code so most people will ignore this.
On your website the link for RouterOS [Learn more] just redirect to home page ... that's a dead giveaway that you are far from complete
I land on a page where there is nothing tellling me who published this page and not any particular detail on what the service (if any) is supposed to do besides:
Sign in to continue
Generate and review RouterOS configs securely.
and how it does it (only as an example it could be too complex for my level of RouterOS knowledge or too simple, and how much secure it is, if it is secure at all, is left to the adverb "securely").
But - without any information about it - I am supposed to give to it my e-mail.
For all it matters it could be a way to gather confirmed e-mails for spamming a targeted subset of internet users (those interested in Mikrotik devices and networking in general) with advertising or whatever.
So I could use a temporary e-mail service to sign in, or decide I won't bother.
Thanks for the detailed feedback @jaclaz , this is genuinely useful. You are right, the landing page gives zero context before asking for an email, and that is a legitimate trust concern, not just a UX nitpick.
I will fix this in the next update:
A proper landing page before the auth wall explaining what the tool does, who built it, and a real example
Clear note on what the email is used for (account access only, no marketing)
Fixing the broken RouterOS learn more link that mozerd caught
Appreciate you taking the time to explain it from a first time visitor's perspective. Will post here once the update is live.
A tool that I would like with respect to RouterOS configuration is one that given a configuration file would be able to reliable to answer "what is going to happen if a packet like this comes to interface", where packet is either a human description or a capture.
That is a solid feature request, basically a packet trace simulator against a static config. Firewall filter chains, NAT, mangle, routing table, the whole path a packet would take without needing a live router.
Noting it for a future version. Would need to parse the full exported config (not just generate one) and simulate rule order evaluation including jump chains, connection state, and address lists. Bigger scope than the current generator but the right direction.
If you have a specific config and packet scenario in mind, happy to see an example of what output format would actually be useful to you (plain english trace, or something more structured like a hop by hop table).
Thank you for sharing the project without the "auth wall".
A simple request to produce the default, out-of-box factory configuration for a specific device results in the tool generating the configuration with certain assumptions, which the tool "thinks" a user needs/wants/asks. And this is a concern.
Perhaps my attitude is showing, but if it's cloud based and requires a login, I'm not touching it for any reason (and the inclusion of Artificial Imbecile knocks it down even further). The info that gets stolen is bad enough, but just giving away core configs is insane. An pen source local installable I might consider . . . the concept isn't bad (but then again, I don't find RouterOS that difficult to begin with . . .)
Good catch, and fair concern. The tool should generate exactly what is asked, not add assumptions the user did not request. If you ask for a factory default config, it should return the actual factory default, not a hardened or opinionated version.
I will add a strict mode that outputs only what is explicitly requested with zero inferred additions, and keep the current AI assisted suggestions as an opt-in toggle rather than default behavior. Will test with a plain factory default request specifically before pushing the update.
No login is required anymore, that was fixed based on earlier feedback in this thread. Configs generated are not stored against an account.
On the AI skepticism, understood, and it is a reasonable default position for anything touching production configs. The tool is meant as a starting point or reference, not something to paste directly into a live router without review, same as any generated config from any source.
Open source local installable is a fair ask and something I will consider for a future version. Right now it is cloud based because generation depends on a hosted model, but a local CLI version that does not need that is on the roadmap.
1. Your AI sovereignty dictates your future. Sovereignty is the precondition for choice. Relinquishing sovereignty transfers your future choices to others, who are likely to exploit it for their gain and your loss.
“What the technical customers want is control over their compute, their models, their data stack, and their alpha. They want to know they own the means of production, and it's not being transferred to someone else..."
Understood, and it is a legitimate lens to view this through, not just for this tool but for cloud AI tooling in general.
Practical answer for this specific case: the input is a plain English description of what you want, not your actual router config or credentials. Nothing proprietary or sensitive needs to go into the prompt for it to work. If you already have a working config, you are not sending it anywhere, you are only describing what you want built.
That said, the broader point about compute and data ownership is fair, and it is exactly why a local installable version is on the roadmap, so people who want zero cloud dependency have that option instead of just being told to trust the hosted version.
The problem is that it never would happen as that "AI" is programmed to "forecast your needs" so it fawns and pulls your teeth to just keep "conversating". The exact answer is not the goal. It's assumed to be kind of therapy session. I wonder when the "big models" start to provide cosy couches to keep your attention?
Fair point on the general behavior. This tool is a single-generation call, though- no chat memory, no follow-up prompts to keep you engaged. You describe it once, get one config back. No incentive to "converse."
The assumption issue randomwalk raised is real and comes from the prompt logic, not engagement seeking. Fixing that directly.
So you have to, at the beginning, "switch off" the built-in talkative nature, forbid data usage/make the talk private, order to answer shortly and on the topic and then. at the end, you can ask the question you want. Seems to be fighting with over-talkative algorithm that wants to politly satisfy you.
Am I missing something? Am I wrong?
