If possible, in the next updates of the Mikrotik and CHR router OS, add the kill switch option in the menu section and by setting it in the kill switch menu, in case of internet disconnection or VPN disconnection, the main internet server of the home or organization will be disconnected in general and the main IP will not be leaked and no site will be opened. It would be great if you add this option for the security of the home or organization's internet.
Please forward this suggestion to the relevant department
Regards
Amir Mahdavi Yousefi**
**Reminder
Since Mikrotik's OS router for routers and OS router for virtual server (CHR) support VPN protocols such as PPTP, L2TP version 2 and 3, SSTP, OpenVPN,IKEV2, etc…, I know that it is possible that this kill switch feature should be added to the popular Mikrotik operating system with different settings and scenarios. It would be great if it were a separate feature in the Mikrotik menu.
Thank you for your attention to the suggestions of MikroTik users and good customers.
Regards,**
RouterOS is not the kind of software where you have that sort of buttons. You need to configure that yourself, e.g. using firewall rules, routing entries, etc.
... and for the typical configurations it's not needed (i.e. already implicitly present). A kill-switch being necessary is mostly exclusive to consumer/end user OS-es.
Is the goal to force internet-bound traffic always uses the VPN, so that client/router never use the ISP internet directly? e.g. so ISP never see anything but VPN traffic?
... If so, this can be done with config to prevent that, either firewall rules or routing rules can do it.
You might want to post your config and clarify the goal as "kill switch" and VPNs is a little vague... A "kill switch" implies a manual process, which is why I'm confused.
No, a “kill switch” is commercial VPN provider language for a feature in their PC client software that automatically disallows all traffic outside their VPN tunnel. As you (and I) wrote, in RouterOS it can be done using some firewall/router configuration, but the OP is accustomed to that being just a checkmark in his VPN software, and requests that to be included in RouterOS.
Not gonna happen, of course, that just isn’t the way a MikroTik router works. He should have bought another brand, I guess…
It is possible to write to the firewall via IP routes and firewall rules, but all scenarios can be implemented in a separate menu called Kill Switch.This feature could be added, it would be great with different settings and scenarios.
Kill Switch is a feature that when the VPN is disconnected, the entire internet is disconnected and the desired site (such as cryptocurrency exchanges and financial sites) that are under sanctions in the United States and Europe cannot be opened and the original IP that is under the country's sanctions is not exposed and the user account is not blocked and no problems arise.
I request MikroTik administrators and programmers to add a kill switch option to the menus along with various settings and scenarios.
Well, in general I think it would be a desirable project for MikroTik to:
remove Quick Set from the main package and put it in a separate package that can be uninstalled
extend the functionality of Quick Set in the direction that this poster would like to see: wizards that do some configuration useful for end-users that are not capable to do the detailed config themselves.
It would make the MikroTik routers more useful to home users, and thus would extend the market.
And at the same time, doing it in a separate uninstallable package allows us (experienced admins) to remove that and protect our routers against inadvertent changes by nosy co-workers.
Even today I had to undo a config change made by a new MikroTik user who thought he had to use Quick Set to change something in a router I already had configured via cmdline. It is a wellknown gripe.
The problem with packages in RouterOS is that they are distributed as separate compressed readonly filesystems. So there is an overhead for having a package, and you can have a package only in its entirety. Deleting a couple of files that are determined to be unnecessary is not possible.
But yes, having niche drivers of considerable size in a separate package could bring something, especially for ARM architecture on 16MB devices. However in the above example it would actually be worse for the ARM device for SOHO offering WiFi and LTE…
Well, as I said, each package has a fixed storage overhead so splitting in many packages incurs that overhead several times, and that could be a problem on devices with little storage when they require all the packages.