I think it would be more useful as a limited-user capability where users can be created that have preciselyGive the ability to secure firewall rules.
Welcome to the Safe ModeFor remote systems it will be not good if the managemend firewall rules are deleted.
Just an example, that's cool:Yes, RouterOS v7 has better command history, you will be able to see specific command that was executed.
> /sys history print detail
Flags: U - undoable, R - redoable, F - floating-undo
U redo=/interface eoip remove bridge2
undo=
/interface eoip add arp=enabled arp-timeout=auto disabled=no mac-address=\
6A:F5:C8:E5:62:12 mtu=auto name=bridge2
action="device removed" by="admin" policy=write time=mar/13/2020 14:06:52
> /interface/bridge/add name=brrr
> /sys history print detail
Flags: U - undoable, R - redoable, F - floating-undo
U redo=/interface eoip add name=brrr undo=/interface eoip remove *3
action="device added" by="admin" policy=write time=mar/16/2020 16:44:09
+1Don't forget to add VRF for management interface!
I'm against that. It is completely useless, and it tends to racism.Consider a GeoIP package allowing for firewall filtering by Country
I think the queue trees should allow an additional form of rate configuration in the form of a percentage of the rate of the next higher level in the queue tree.Enable using a global "MAX Speed" parameter you expect on your WAN interfaces. This should then be possible to be used within routeros within queue trees, mangle rules, hotspot etc. Today one needs to define each time an absolute value for Max Limit, Buffer Limit, trigger limit etc.! What a nightmare.
WiFi6 ist 2.4 and 5 GHz.WiFi 6 ( 6 GHz )
lmao, oh god, political correctness has now extended to routers.....I'm against that. It is completely useless, and it tends to racism.Consider a GeoIP package allowing for firewall filtering by Country
My first claim is that it is useless. And I will explain that:lmao, oh god, political correctness has now extended to routers.....I'm against that. It is completely useless, and it tends to racism.Consider a GeoIP package allowing for firewall filtering by Country
There are very good reasons for country blocking, first and foremost is for many people there's absolutely zero need to allow ANY kind of incoming traffic from overseas. All of our routers i'd absolutely like to do a simple chain=input src-country!=Australia action=drop. There's absolutely zero need for anyone in any other country to have any kind of input to our routers, except maybe ICMP. I'm not peering directly overseas, nobody will ever need to login or establish VPN's from overseas etc
Ideally this would pull data periodically from a central MikroTik server similar to DDNS which would make it more effective than just using fixed address-lists
That's a very simple and effective rule that would drastically reduce any vulnerabilities whilst simplifying management. If you feel thats racist well.... thats your problem
You may think so. Take an example. On your server you have a small web server that is for you local bicycle club. There user can get information about training times, when there are competition etc. Lets say a someone from Australia is on vacation in Bali and wants to know when the training is for his son that are home in Australia. Why should he not do that.There are very good reasons for country blocking, first and foremost is for many people there's absolutely zero need to allow ANY kind of incoming traffic from overseas.
My claim was: It is completely useless, and it tends to racism.So I don't know whether using discrimination per country is racist, but it is definitely useless.
Hmm. here is a counter use-case:My claim was: It is completely useless, and it tends to racism.So I don't know whether using discrimination per country is racist, but it is definitely useless.
It is useless for the reasons I described, and it tends to "let's block Nigeria because Nigerians are scammers. let's block Russia because Russians are hackers", etc etc.
That quickly slides towards racism.
As I explained before, that is not going to work. Your own users may appear to come from another country.Imagine you have a service for users from your own country only.
Then it makes sense to block all login attempts from any other country.
Q.E.D.![]()
this is was nearly my user-case. a local WISP. and at one point it was very attempting to do so to fence off all failed authentication to our VPN service. Most of them are from one country.Imagine you have a service for users from your own country only.
And as I did write, how to access these services if the user are out travelling in another country?Hmm. here is a counter use-case:
Imagine you have a service for users from your own country only.
Then it makes sense to block all login attempts from any other country.
Q.E.D.![]()
You are WAY overthinking this. It's really as simple as an address list generated from IANA that says i.e.My first claim is that it is useless. And I will explain that:
You have not defined what "the country of an IP address" is, and neither has the internet.
That would not be an 'input' chain, that would be forward chain, so the rule would not block traffic going to a server that resides behind the router. Only traffic directly destined to the router itself would get blockedYou may think so. Take an example. On your server you have a small web server that is for you local bicycle club. There user can get information about training times, when there are competition etc. Lets say a someone from Australia is on vacation in Bali and wants to know when the training is for his son that are home in Australia. Why should he not do that.There are very good reasons for country blocking, first and foremost is for many people there's absolutely zero need to allow ANY kind of incoming traffic from overseas.
Or your work have an proxy or head quarter in an other country, he the could not open your local web server, since you blocked all from outside Australia.
But if you have no webserver nor other services needed for any other, block it 100% for all, not just for people from overseas. Use VPN to access your local resources if needed.
It isn't useless. It's not about 100% perfect security either (such a thing doesn't exist). It's just about reducing the broader attack spectrum. In the same way most people move the default Winbox port off 8291 to something else, that isn't 100% effective so therefore its a useless feature? may as well not have it?If someone wants to attack you specifically, it is not a big deal for them to use a zombie device in your own country as a proxy. The internet is full of vulnerable devices which have never been upgraded since unpacking. So I don't know whether using discrimination per country is racist, but it is definitely useless.
Then Is see what you do wrong. There should be no input rules coming from the outside using the input chain. VPN is the way to go if you need to access services on the router.That would not be an 'input' chain, that would be forward chain.
I'm sorry to tell you, but that isn't possible. Addresses have not been assigned that way! I also sometimes thought it would have been much betterIt's really as simple as an address list generated from IANA that says i.e.
1.x.x.x/8 = Belongs in USA.
2.1.x.x/16 = Belongs to Belaruse
3.x.x.x/8 = Australia
etc etc
Functionally identical to an address list allow/block rule, except without having many thousands of entries in the address list and cluttering it up.
I am entirely aware of this, what I provided was clearly just an oversimplified example, I thought that was clear when I mentioned 'instead of having several thousand address list entries'I'm sorry to tell you, but that isn't possible. Addresses have not been assigned that way! I also sometimes thought it would have been much better
when it had been done that way, but it hasn't.
LIRs have assigned /24.../16 blocks to "users" (companies, internet providers) completely randomly, within their region. So it is rarely possible
to aggregate subsequent blocks into larger blocks that represent a country. The blocks for Australia are completely intermixed with blocks for
the asia-pacific region. The list of blocks for Australia would have many thousands of entries no matter how you like that.
I hoped you would have understood by now that this is not possible because there is no simple attribute on a packet that indicates it is "from Australia" so such filters can only work with that address list of thousands of entries in place.I am entirely aware of this, what I provided was clearly just an oversimplified example, I thought that was clear when I mentioned 'instead of having several thousand address list entries'
It's doing exactly the same job as manually adding them to an address list. But in a very simplified and clean way by just enabling 1 option and specifying countries. Ideally that is then dynamically updated
The alternative is entries need to be manually added to a MikroTik, that could be hundreds/thousands of routes especially if I want to do multiple things with multiple countries
Then I need another script running that updates this list automatically...... it's just really messy to keep everything updated and everything in sync.... when it could be a simple 1 tick-box operation instead.
The use of separate packages for part of functionality (like routing, advanced tools, PPP, etc) has been abandoned in v7. Everything is now in a single package except the truly special things like UPS monitoring.Please can upload All packages as separated files then we can use fetch command also , add Https mikrotik certificate for url download.mikrotik.com
installing packages required unzip the file and upload it agian some sites time we use mobile network and slow connection.
Remember, you don't need to convince anyone in this forum, just MikroTik. Non-technical reasons and user's business decisions aside, first question is what exactly should MikroTik provide. I see big difference between just support for something and providing all the data.So why are you so opposed to having a country feature?
But you can just handle them in the input firewall, right? That is where I regulate the other services as well, when they are enabled.The problem is the dude service on ports 2210 and/or 2211. They are not in the IP-Services settings.
The huge big network security problem is you can't turn this off or limit IP access in the IP-Services settings !!!!!!
Never mind - I got an email that says Dude uses the same ports as Winbox.Put Dude ports 2210 and 2211 in IP-Services where it belongs
Currently , IP->-Services has a field "Available From"
This functions with api , api-ssl , ftp , ssh , telnet , winbox , www , www-ssl
These services can be turned off/on and/or blocks of IP-networks can be used for each service.
The problem is the dude service on ports 2210 and/or 2211. They are not in the IP-Services settings.
The huge big network security problem is you can't turn this off or limit IP access in the IP-Services settings !!!!!!
This client Dude service is running and there is zero IP-Services control. This is a huge gigantic bulging security problem !
Every day, I see thousands of entries in my Mikrotik logs - example "jun/25 13:32:09 warning denied winbox/dude connect from 185.209.0.62"
Yesterday , I counted 4-thousand "winbox/dude" connect logs. And I know it's not winbox because I IP-Services limit what IP blocks can connect using winbox , so it has to be dude !
I suspect this has the potential to allow remote break-ins where an attacker may be able to do anything they want to your Mikrotik.
Also - it might be a good idea to add ICMP to the IP-Services section
North Idaho Tom Jones
That is normal for using that kind of limit. As I already wrote, the service accepts the connection then drops it and logs a message.And why do I still get "warning denied winbox/dude connect from" indicating remote IP addresses in my logs when I have the IP-Services for winbox configured to only allow my IP address blocks ?
Again - thank you for your prompt reply(s) to my questionsThat is normal for using that kind of limit. As I already wrote, the service accepts the connection then drops it and logs a message.And why do I still get "warning denied winbox/dude connect from" indicating remote IP addresses in my logs when I have the IP-Services for winbox configured to only allow my IP address blocks ?
When you do not like that, add a firewall rule (probably with address list) for the filtering.
Yes, that is how it works. In Linux this is called "TCP Wrappers" with their associated config files "/etc/hosts.allow" and "/etc/hosts.deny". It sits between the listening TCP port and the daemon that runs the connection, it first accepts the connection (or rather the kernel does that), looks up the source network in those files, and if not allowed it just closes the connection again. This whole thing was invented before firewalls were available in operating systems.Question - Am I correct to assume for IP-Services ssh, telnet, http, https api … Is it also "service accepts the connection then drops it if not allowed" ( aka accept the connection , check access-list, then drop if not allowed - if allowed then continue the service connection) ?
You can make a jump rule and add multiple rules to it, all with an address list. Not exactly the same, but should work.option to specify multiple adress lists inside single firewall rule?
No, it's bad idea. USB Stick are detected and dhcp-client is automatical created, you can do many fix to your needs by scripts&schedulers.Add support for LTE Devices to be controlled via CAPsMAN
That's right yes. reason = "Shutting down because DHCP broken script triggered a restart."When the reason for the reboot is an upgrade of ROS, the router already logs that...
Maybe it was just an unfortunate example and you want to be able to specify other messages like "shutdown for maintenance in rack #2"?
No, you are misunderstanding my request. I want to be able to specify the reboot reason in a script. For example: I have 10 scripts each that have a set of sequences that might lead to a reboot. Now my router reboots due to 1 of these scripts. It's hard for me to determine which one. If I could in each script give it a unique reboot reason by calling /system reboot reason="blah" then I'd be able to immediately see after reboot which one of those scripts initiated the reboot.If the reboot reason is written to the log before syslog is up and running, it will not send it out externally. So you need to look in local logs.
When you are doing such advanced things, I would advise setting up an external logserver and do remote logging to that.No, you are misunderstanding my request. I want to be able to specify the reboot reason in a script. For example: I have 10 scripts each that have a set of sequences that might lead to a reboot. Now my router reboots due to 1 of these scripts. It's hard for me to determine which one. If I could in each script give it a unique reboot reason by calling /system reboot reason="blah" then I'd be able to immediately see after reboot which one of those scripts initiated the reboot.If the reboot reason is written to the log before syslog is up and running, it will not send it out externally. So you need to look in local logs.
Yes, that would be a useful approach. Unfortunately I operate in an infrastructure-less environment where the configurations are built up and destroyed dynamically and as such we don't have a syslog server option.When you are doing such advanced things, I would advise setting up an external logserver and do remote logging to that.No, you are misunderstanding my request. I want to be able to specify the reboot reason in a script. For example: I have 10 scripts each that have a set of sequences that might lead to a reboot. Now my router reboots due to 1 of these scripts. It's hard for me to determine which one. If I could in each script give it a unique reboot reason by calling /system reboot reason="blah" then I'd be able to immediately see after reboot which one of those scripts initiated the reboot.If the reboot reason is written to the log before syslog is up and running, it will not send it out externally. So you need to look in local logs.
Then you can also keep log messages that occurred just before a crash, including messages you write in the log from a script.
You can easily set this up on any Linux machine, e.g. a Raspberry Pi or similar.
Isn't that what's already supported? https://wiki.mikrotik.com/wiki/Manual:I ... or_Classes- vendor class identifier (a string)
In the light of MAC address randomization it becomes less and less useful...- MAC address (a value and a mask)
Ok I was not aware of that. Indeed it is most like what I need except that I would like an extra match capability on MAC address/mask.Isn't that what's already supported? https://wiki.mikrotik.com/wiki/Manual:I ... or_Classes- vendor class identifier (a string)
But that is in fact one of the the applications I have for it :-)In the light of MAC address randomization it becomes less and less useful...- MAC address (a value and a mask)
Exactly. There are a few good use cases where client device MAC randomization doesn't make any sense and it's good to have some way to remind users to switch off MAC randomization for a particular SSID.But that is in fact one of the the applications I have for it :-)In the light of MAC address randomization it becomes less and less useful...- MAC address (a value and a mask)
You may be surprised as a network engineer, but SWos does not require this information!Can I have a link to the Feature requests for SWos
I am looking for feature of subnet mask default gateway on SWos software.
Without this feature it is impossible to manage/monitor a MikroTik device running on SWos from a different subnet. I am surprised it is omited and is a major limitation.
Regards,
David
Network Engineer, CCNA
They listing at that post :) and now... ros7.1beta3Feature request: add do-not-round option for /ping. (or accuracy=1/10, 1/100, 1/1000 or so)
Currently the /ping utility rounds to ms, which accuracy is enough in most cases. However, there are situations where there is a serious need for greater accuracy, e.g. gives a linux ping.
SecondedWinbox is wonderful, but a small suggestion: consider adding snapping capabilities to the several windows that can be opened within Winbox. It would be much easier to organize it.
Thanks.
I refer to the option you have in Windows: select the title bar of the window you want to snap, and drag it to the edge of your screen. An outline indicates where the window will snap to once you drop it. Drag it to the left or right side of your screen depending on where you want to snap it to. Some other interfaces allow you to snap windows against each other.Maybe you should explain what "snapping capabilities" are?
I like your taskbar aproach and the access to the open windows. And also compatible with the tile suggestion.Oh... well I prefer stacked windows rather than tiled ones, and I would like to see a "taskbar" or similar feature where you can click windows that have gone buried under others, to raise them again. Or some "lower" function that you can click in a large window to move it back to the bottom of the stack.
In daily use I usually have a "log" window full-sized as backdrop and open other windows on top of that. When I advertently click on the log somewhere it raises that window and all other windows disappear behind it. They can be raised only one by one via the menus, but it would be convenient when the log window could be moved back to the backdrop and/or when a list of open windows can be seen or called.
Easy for a teddy bear with straw for a neck!!!at Win10 we can Snap windows by Win + [Left/Right arrow]. For working with 3 monitors it's OK.
That feature has been present for years. But people don't bother to really study the matter so they often will not find that by themselves.As for features I believe I read this somewhere recently where someone was suggesting firewall lists within firewall lists.
That way we can select a number of firewall lists into a group of their own and so on.
That makes no sense! TCP and UDP are different protocols, they cannot be grouped.more important for me will be a selective protocol not only TCP or UDP and creating double rules but have a protocol list 6 TCP + 17 UDP in one FW RULE - this can grup my firewall rules drastically.
As I said before: people don't bother to really study the matter so they often will not find that by themselves.Access List of other Access List will be greate like the rules like a one regex: 10.50.[128-254].[30-35] who will match my all 128 branches with printers range in each branch - now I generate 128 rules for one LISTs in Access List.