Request - CHR ISO to allow CHR install on a bare metal platform.
Reason for request: #1 - CHR running on the free version of VMware ESXi has a limitation of 8 CPUs per virtual hosted system. #2 - The cost of VMware ESXi license to enable greater than 8 CPUs to a virtual hosted system can be quite expensive.
An ISO install version on a bare metal box could permit the following:
Boot on USB (bare metal BIOS configured to make the USB appear as an IDE drive).
Utilize E1000e ethernet interfaces (10-Gig).
Utilize all cores (dual multi-core Xeon CPUs). Example - two Xeon CPUs with 28-cores (not counting HT), could allow a CHR to function with 56 (or much more) Xeon CPUs.
A bare-metal CHR may be up to hundreds of times faster than a virtual hosted CHR (with 8 CPUs), running hundreds/thousands of complex firewall rules.
I have tried x86 on bare metal , but I’ve experience X86 ROS lockups under heavy loads.
I am researching a v-to-p (virtual machine to physical machine) conversion - and it may be possible - but uncertain and untested.
Can’t believe that RoS console still doesn’t have such basic feature as a command history search !
Like Ctrl-R/Ctrl-S in bash. Type Ctrl-R then few letters and it will show you previous command from the history with these letters, with Ctrl-R to move to the next result up and Ctrl-S down.
And no filter in log viewer in Winbox even after numerous requests ?
There are several discussions in these and other forums about how to implement port knocking in RouterOS. And, at a basic level, they all can work.
In short, they tend to be “detect proto on port, add src to address-list KNOCKPHASE1”, “detect proto on port2 when src already on address-list KNOCKPHASE1, add src to address-list KNOCKEDSUCCESSFULLY”, “allow in when src on address-list KNOCKEDSUCCESSFULLY”.
The problem is that certain types of port scans can trigger this.
So we’d also want “… and src has NOT appeared on any OTHER port, or on these ports in the wrong order”.
That turns out to be messy with RouterOS as it is today. Possible, but messy. (At the least, you end up with ports on both a successfully-knocked list AND a blacklist, and rule execution order plus the admin having a good memory or good documentation is required to avoid mental confusion…)
So, a feature request for RouterOS, formal, flexible port knocking.
Knocking should allow any combination and order of ports and protocols, up to N layers deep. (At least three. e.g. TCP/4321 followed by UDP/7654 followed by ICMP type 8 subtype 0)
The formal port knocking implementation offered as part of RouterOS should have, built-in, an optional “… and no other traffic from src in the past few seconds/minutes”. (That’s the part that’s hard to implement cleanly with today’s RouterOS).
I think that does not fit within the design philosophy of RouterOS (where you get low-level tools rather than high-level blocks that perform a complex task).
However, a reasonable request would be to implement a new firewall rule action “remove src from address list” (and maybe “remove dst from address list”),
which would allow you to build what you want using the existing “add” action to add addresses to a list as they walk through the desired port knocking steps,
and use the “remove” action when they do things that do not match your desired steps (so they fall back to initial state).
I’m sure that MikroTik can easily write their own ACME client. But it’s even more important how it should fit into RouterOS and work for as many scenarios as possible.
For example, maybe you just want certificate for https WebFig (or SSTP server). Sounds easy, right? There’s already a webserver on router, so simple http-01 validation can be used. But what if you don’t want or can’t open port 80 (AFAIK http-01 always starts with plain http on standard port 80)? It would be the case on at least half of routers where I’d like to use Let’s Encrypt certificates, because there’s typically only one public address and standard http(s) ports are already forwarded to some internal webserver. There would have to be support for dns-01 validation and it has different problems too.
I think it’s doable, I tried some suggestions in Support for ACME/Let’s Encrypt certificate management thread, but so far it doesn’t look like anyone from MikroTik though “oh yes, it’s super-awesome, we need to have that!” Maybe try to invent some other foolproof plan that will finally convince them.
From the manual page (https://ndilieto.github.io/uacme/ ), it appears uacme supports dns-01 challenges and allows total flexibility by the --hook option, which calls an external script to accept, decline or set up the challenge environment.
If specified, uacme executes PROGRAM (a binary, a shell script or any file that can be executed by the operating system) for every challenge with the following 5 string arguments:
METHOD one of begin, done or failed.
begin is called at the beginning of the challenge. PROGRAM must return 0 to accept it. Any other return code declines the challenge. Neither done nor failed method calls are made for declined challenges.
done is called upon successful completion of an accepted challenge.
failed is called upon failure of an accepted challenge.
TYPE challenge type (for example dns-01 or http-01)
IDENT The identifier the challenge refers to
TOKEN The challenge token
AUTH The key authorization (for dns-01 already converted to the base64-encoded SHA256 digest format to be provisioned as _acme-challenge DNS TXT record).
First - this may sound like a bit of a strange ROS feature request , but this would be a very powerful feature that no other wireless company can offer at this time.
A bit of my background so that you understand my reasoning for this request :
As a WISP (and fiber-to-the-home ISP), we have hundreds of Mikrotik APs and 1,000+ client Mikrotiks
All APs use the same SSID
All of our tower locations have multiple (dozens) of APs on each tower (all with the same SSID)
Clients (nv2 Mikrotik clients) do not necessary connect to the strongest/best AP which may be facing in the direction of the client Mikrotik. As a result, we often have many many client Mikrotiks that are not connected to the best/strongest AP. This often results in everybody on that AP running a little slower because of the few clients that are connected with slower connect rates and higher wireless retries.
So , after more than 10+ years of hands-on experiencing clients often not connecting to the most preferred Mikrotik AP, I have a feature request to ask Mikrotik for …
Feature request #1
A new SSID setting for Mikrotik wireless clients (802.11 & nv2 & nstream)
A new optional setting on the client SSID that is a dont-care character.
With feature both feature request ( 1 and 2 above ) , Mikrotik clients now have a preferred ordered connect SSID list. If the 1st and 2nd SSIDS are off-line, then the Mikrotik client will try to connect to the 3rd SSID selection in the list. If the first 3 preferred SSIDS are off-line, then the client Mikrotik can use the dont’care character and connect to any other matching SSIDs.
Something like this will surely help any WISP using Mikrotik products who have a large base of Mikrotik wireless devices.
With these 2 new requested features in Mikrotik ROS clients, a WISP can now; A - have some control as to what APs client Mikrotiks connect to & B - configure client load sharing on all WISP APs.
FYI - and yes I do know there is a connect-list feature that uses signal strength (for APs and clients) but that feature also has it’s own other set of issues and problems.
Why use SSID for this? This may bring compatibilty problems. Wouldn’t a preferred list of AP’s (e.g. by address instead of SSID) on the client alone help with your issues? So no change on the AP side necessary.
Yea , using a connect list with MAC address could almost work (almost).
Using a MAC address connect method presents a management problem for all clients when an AP needs to be replaced or upgraded.
A change of an AP, can result in a different MAC address , which then can result if every wireless client needing to be re-configured.
Thus, if you have 300 clients connecting to a tower with more than one AP , then you can end up with 300 clients that need to be reconfigured/re-programmed.
I’ve been down this road many times in the past and it ain’t pretty.
Re compatibility problems - that is the reason I stated optional setting. Default on an upgrade to a newer ROS with such a feature should be default Off.
It would be great if dhcp-server has an option to set a queue limit to each lease, and remove when the guest got out, automatically.. or RouterOs already does that?
When you have to manage 300 devices you should have some mechanism in place to support remote management.
It can be done with MikroTik. I have seen solutions for that presented at MUM events.
E.g. you make a scheduled job that runs once a day and attempts to download some file with a naming convention depending on the client, and when it exists it imports that file.
(it would be a good idea to have some version numbering so you can avoid re-running the same file every day after it has been already run once)
There should be more explicit support for that in the Dude.
Re: … mechanism in place to support remote management …
I have my own custom scripts (Linux for-IPs-In-a-List.txt ssh/telnet send/expect) which work very well to bulk manage my client Mikrotiks.
Re: … good idea to have some version numbering so you can avoid re-running the same file …
My custom management scripts do this and much more
The problem with bulk management is configuring an algorithm which does two thing - 1; load share connected clients on APs and 2; define a set of client preferred APs to use when available.
With my two requested features, these new settings would only need to be performed when the client is installed.
The issue is that there is a whole bunch of Mikrotik admins that do not use Dude or custom scripts and only manage client Mikrotiks manually one-at-a-time.
With my suggestion, there would be no need for any type of bulk management (if any AP is replaced) if my two feature requests would be implemented in ROS.
I have multiple clients windows and Linux. and need multiple usernames to have different routes pushed to them, as-well as a global route push. so I don’t have to have seperate vpn servers. or multiple client config files and have to worry about user having right config file.
The current routes option in ROS is the iroute command for the ccd files. and it puts routes into the routers/servers routing table to the clients lan.