Free RouterOS configuration generator (browser-based, no account)

3rd party tools
21

Hi rextended, one of my collega`s look at it, this is his reply :slight_smile::slight_smile:

Thanks for taking the time to test it. Point by point:

Brute-force protection. You are right and it is changed. It is now off by default. Your spoofing argument is the decisive one: the rules match on new TCP connections, so a forged source address can get an arbitrary address onto the ban list, including the admin's own. On top of that, CGGXANNX made the complementary point in this thread: with the default rule set in place, everything from WAN is already dropped by the final rule, so the escalation lists were tracking addresses of packets that were dead anyway. The only role that still enables it is the harden-only baseline, which runs without the default rule set, so there the lists are the actual protection. The toggle is still there for anyone who deliberately exposes SSH or WinBox, and the help text now spells out the trade-off.

Automatic updates. Here I have to push back: that option is off by default. It is an opt-in toggle, and the help text says the router reboots when it installs. We are not pushing unattended upgrades onto anyone. The only thing set automatically is /system routerboard settings set auto-upgrade=yes, which is the RouterBOOT firmware matching the installed RouterOS on the next reboot, not a RouterOS update.

defconf. Already renamed to genconf after jaclaz raised it, and the importer still recognises the real defconf so an existing config round-trips.

bandwidth-server. Already set enabled=no by default.

RSTP. Our bridge default is already protocol-mode=rstp, matching RouterOS.

Password field. Fixed. The input had been squeezed to 26 pixels by the two buttons next to it. They now wrap below the field.

Device mode. This is the most useful thing in your post and nobody else raised it. The generator now inspects its own output and, when it uses something device-mode can gate (scheduler, container, hotspot, fetch, ipsec, l2tp and so on), it says so, names the features, and gives the print and update commands with the note that the change needs physical confirmation. Yes please on the delayed self-destructing schedule trick, that would be a good addition. (Thanks for this! Very good idea!)

Everything disabled=yes, enabled at the end. I understand the concern but I am not doing it that way. A large part of the value is that the output reads like an /export and can be diffed against one, and inverting every line would cost that. The lockout risk is real though. If what you mean is a scheduled rollback that restores the previous configuration unless you cancel it within a few minutes, that I would happily add as an option. Let me know if that is what you had in mind.

VLAN 1 and reserved numbers. Added. VLAN 1 and 4095 now produce a warning.

All of the above is live now.

22

The 1st rule is that new posts from the new forum users are queued to be moderated.
After some posts they would go without acceptance.
Despite this whole topic spans over 20h so no need to say "it takes several hours to have post accepted".

As I said: we, moderators, are not machines or AIs that never sleep. Sometime "you" (the new users) fall into our "sleep time", "I do not have mood to read the forum", "have no time" ,"I do not know if I should accept that post and I have to think it over".
Sometimes it is just "I can't think about that right now. If I do, I'll go crazy. I'll think about that tomorrow.". We are humans.

23

Totaly agree! It is for us readers and posters to take into account :slight_smile:

24

Well... Thank you, that's a nice compliment for me.

25

On the script, before the end, add a Scheduler that apply all the unapplyable config at the moment because device-mode (each device has own default)

The script on scheduler have a delay of 60s as first line, and is run at "start".
At the end of the scheduler, simply the scheduler delete itself, for avoid apply again at any restart.

And at the end of the wizard script (not the scheduler):
/system device-mode update activation-timeout=1d mode=...

At that point, simply turn off the device within a day,
and upon the next reboot,
the device mode will be set as you want and the scheduler will finish configuring the parts blocked by device mode.

26

The rule drop dst-address-list=bad_dst_ipv4 blocks 224.0.0.0/4 (Multicast).

Problem: This completely breaks local LAN protocols such as mDNS (AirPlay, Chromecast, printer discovery), SSDP/UPnP, and dynamic routing protocols like OSPF/RIP (if in use).

Or am I wrong about that?

27

224.0.0.251, so yes, is in the same pool.

/ip firewall raw
[...]
add action=drop chain=prerouting comment="genconf: drop bogon IP's" dst-address-list=bad_dst_ipv4
[...]
28

@roe1974 You are right, and thank you!, that is a real bug in the documentation "Building Advanced Firewall page" and it is fixed now.

bad_dst_ipv4 contains 224.0.0.0/4, and the rule dropped it in RAW prerouting on every interface, so mDNS to 224.0.0.251 and SSDP to 239.255.255.250 were dropped on the LAN side as well. AirPlay, Chromecast and printer discovery would not have worked behind a generated config. OSPF would have been hit too, although in practice our core router role turns the bogon rules off, so that one was not exposed.

For the record on where it came from: this is taken from MikroTik's own Building Advanced Firewall page, including the address list contents and the unrestricted drop. We copied it faithfully, but we chose to ship it as a default, so the consequence is ours.

The fix: the two destination bogon rules now carry in-interface-list=WAN. Bogons are an internet problem, so the rule belongs on the WAN side, which keeps exactly what it is for and leaves the LAN alone. The source rule is deliberately left unrestricted, because a packet claiming a multicast source address is invalid wherever it appears, and it never matches mDNS, whose source is unicast.

That fixes the LAN, but it leaves a second case that the same rules break: provider IPTV. Multicast arriving from the WAN is still dropped, which is correct for a normal router and wrong if your ISP delivers television as multicast. So we added an option for that as well, off by default, on the uplink step.

Turning it on changes four things, because opening one of them alone does nothing:

  • 224.0.0.0/4 is removed from bad_dst_ipv4, so the stream is not dropped in raw prerouting
  • chain=input action=accept protocol=igmp, so IGMP from the provider reaches the router
  • chain=forward action=accept in-interface-list=WAN dst-address=224.0.0.0/4, placed before the "drop all from WAN not DSTNATed" rule, otherwise the stream dies one rule later
  • an IGMP proxy: the uplink as upstream, the bridge as downstream, with alternative-subnets=0.0.0.0/0 on the upstream because the sender sits inside the provider network and not on the WAN subnet, and without that the proxy ignores it

Multicast stays in bad_src_ipv4 in both cases, so nothing that was closed here gets reopened.

If your provider delivers TV on its own VLAN, add that VLAN as a second uplink and the option lets you pick which uplink carries IPTV. There is also a warning if IGMP snooping is off on the bridge, since otherwise the stream is flooded to every port.

@rextended thanks for confirming the address!

29

@rextended The delayed self-destructing schedule is implemented and live. Thanks again, it is a good trick and it solves a problem we had no answer for.

How it works in the generator: it is an advanced option, off by default, in the System section. That distinction matters, because a normal router configuration has nothing blocked by device-mode and would only take on risk from this. It is meant for the exotic cases, so you switch it on deliberately.

With it on, the generator looks at its own output, finds the commands device-mode can refuse, takes them out of the main script and puts them in a script called genconf-devicemode. A scheduler runs that at startup, the script starts with :delay 60s, and the wizard script ends with /system device-mode update activation-timeout=1d plus the flags. Power cycle within the day and the rest applies itself.

Three things I did differently from your version, and I would like your opinion on all three:

  1. Individual flags instead of mode=. We emit activation-timeout=1d hotspot=yes, only what that particular configuration actually needs. Setting a whole mode felt like it grants more than the user asked for.
  2. It removes itself only after the commands succeed. The body is wrapped in :do { ... } on-error={ :log error ... }. Your version always deletes, which is cleaner, but if the deferred part fails I would rather be left with a scheduler and a log line to look at than a silently half configured device and no trace of why.
  3. The power cycle is a warning, not a footnote. The generator refuses to be subtle about it: a warning in the interface, and a comment block in the script itself saying that if you skip the restart, none of it is applied.

One hole I could not solve, and you may well have an answer. The scheduler is itself gated by device-mode. If a device ships with scheduler=no, the bootstrap cannot create the scheduler that would fix device-mode, so it cannot lift itself out. For now we detect that case and tell the user to set device-mode by hand first. Is there a way around that, or is manual intervention simply the floor there?

30

in fact it must be done in full, my ellipsis was to indicate the command, not the option, in fact it could have been misunderstood. :sweat_smile:

# change only what is not already on [BASEMODE]
/system device-mode update activation-timeout=1d mode=[BASEMODE] flagged=no pptp=no optiona=yes optionb=no

My post about all modes and options:

Variations.

I didn't understand this one, it's assumed that whoever uses the script knows this.

These are the "home" devices. At that point, if the script is used by netinstall, with the appropriate parameters that configure the device mode...

31

@rextended Understood on the ellipsis, that one is on me. I read mode=... as "choose a mode" and argued against a point you were not making. The correction is taken.

Before I change what we emit, one question, because it decides the answer and I would rather ask than guess.

Right now the generator emits only what the configuration actually needs, for example:

/system device-mode update activation-timeout=1d hotspot=yes

Does update leave the options you do not mention alone, or does it reset them to the base mode's defaults? Your "it must be done in full" and the # change only what is not already on [BASEMODE] comment read as the second, in which case that line is not merely minimal, it is destructive: it would silently switch off container, fetch or anything else the user had already enabled. The CLI reference is only a parameter table and does not say either way, and I have no way to test it from a browser tool.

If the answer is that unspecified options reset, we will emit the full form. The awkward part is that a generator cannot know the device's current base mode, since it varies by model and by version, so we would have to emit the whole command with the base mode left for the user to fill in, or read it from a pasted /system/device-mode/print. If you have a better idea there I am listening.

On the other two: the self-removal stays as a variation, and I will keep the power cycle warning loud. You are right that anyone who knows device-mode already expects it, but the people this tool is for are exactly the ones who do not, and a device sitting half configured because someone skipped a reboot is an expensive way to learn.

The scheduler question you answered, and your mode tables answered it twice over: home mode ships with scheduler: no, along with fetch, sniffer, romon and email. The generator now says that explicitly rather than the vague "set device-mode by hand" it said before. It names home mode, tells the user to check /system/device-mode/print, and points at netinstall for the case where the device cannot lift itself out. Thank you for that list, it is more useful than the documentation.

32

NO, is changed ONLY what is specified.
Your example enable only hotspot without doing anything more.

33 
/system device-mode update activation-timeout=1d mode=advanced partitions=yes routerboard=yes

End off all device-mode problems (except, obviously, first time...)

34

nah, simply provide

/system device-mode update activation-timeout=1d mode=advanced partitions=yes routerboard=yes

for first time to reboot the device or press any button on device (mode or reset or wps)...

35

@rextended That settles it, thank you. Since an update only changes what it names, what we already emit is correct and I am leaving it alone:

/system device-mode update activation-timeout=1d hotspot=yes

Worth saying that asking rather than assuming saved us here. I had been ready to "fix" this into the full form, and that would have been the damaging change: naming a mode is itself something specified, so mode=advanced resets every other flag to that mode's defaults. A generator that does not know what the user already had enabled would have quietly switched things off in the name of being thorough.

Your one-liner is now in there as a second choice, next to the default:

/system device-mode update activation-timeout=1d mode=advanced partitions=yes routerboard=yes

The default stays surgical, because the tool knows exactly which flag the configuration needs and there is no reason for it to hand out socks, proxy, bandwidth-test, hotspot, zerotier and the rest to a router that will never use them. But your approach is the right one for anyone commissioning devices who would rather set it once and stop thinking about device-mode, so it is offered explicitly, with the list of what it grants spelled out next to it.

One thing your mode tables caught that I would have missed: since mode= resets to that mode's defaults, and advanced has container=no, picking that option on a configuration with containers has to name container=yes again alongside it, otherwise the mode change quietly undoes the thing the bootstrap exists to enable. Same for traffic-gen. The generator does that now, and there is a test for it.

Your defaults list has been more useful to us than the documentation page. Thanks for putting it together.

36

:slight_smile:
thanks!

37

... as often happens with what rextended :slightly_smiling_face: posts, once you get over the grumpiness ... :wink:

38

I'm being genuine, rather than grumpy.

I've seen some good things in what he's doing, and I made that clear in my first post...

:innocent:

39

containers=yes as well?

Unless having a feature enabled and not using it somehow consumes resources, I'd think that just enabling everything from the get-go would be the best choice (although containers on a fairly weak AP makes little sense realistically . . .).

40

@tadawson You are right about the resources, and I think that is exactly why the conclusion does not follow. An unused device-mode flag costs no measurable RAM or CPU, because it is a permission gate rather than a running service. But resources were never the cost. The cost is what a compromised router is allowed to do.

Device-mode exists to limit blast radius after something goes wrong, and the flags a blanket unlock hands over are the ones with the worst history: fetch to pull a payload, scheduler to make it persistent, container to run it, and install-any-version to drop back to a RouterOS with a known hole. Enabling all of that on a device that will never use any of it is precisely the posture device-mode was introduced to prevent. So "on by default because it is free" is true on resources and expensive on everything else.

For the generator specifically, we are in the fortunate position of not having to guess. The default option names only the flags the configuration actually uses, so a config with containers in it emits container=yes and a config without them does not. That is better than either blanket answer, and it is why the surgical form is the default.

The "unlock everything" choice is deliberately rextended's command and not my own extension of it. Once I start adding flags he did not include, it stops being the well understood one-liner people recognise and becomes my opinion wearing his name.

On containers in a blanket unlock, there is a tidier answer than bolting container=yes onto advanced: rextended's own mode list shows ROSE is advanced plus container. So the mode you are describing already exists. I have not put it in the generator because his list marks it as undocumented and tied to ROSE storage devices, and I have no way to confirm an ordinary router accepts it.

And your aside is the strongest argument for the approach we took. Containers on a weak AP make little sense, which is a good reason to let the configuration decide the flag rather than granting it to every device that passes through.