Hi All,
I recently had the need to install a CHR on a Air Gap virtual infrastructure on customer premises.
Although, the CHR P1 license seems to work ONLY on systems which are constantly connected to internet, due to the frequent verification of the license validity and expiration date against some of the Mikrotik public servers.
Personally I tried to install a CHR on a separate infrastructure, then I purchased a P1 CHR license for that. But when I backup the CHR VM and restore on another infrastructure (ESXi, or Proxmox) the license became invalid due to the new “system-id” that gets generated by the CHR when it detects it is laying on a different hardware (or virtual.hardware, in this case).
Since an Air Gap system is by default isolated from the rest of the networks, how can I solve the problem?
In other words: How can I install a CHR in a Air Gap Virtual infrastructure and then manually assign a purchased license?
Alternatively: How can I install a CHR in a public infrastructure and then move to Air Gap System without losing the license?
Create your CHR vm and the interfaces you want to use ( no configurations - no configuration ).
Add one more interface to the Proxmox vm
Power on the Proxmox CHR vm
Use Winbox of MacTelnet and connect log-into your new CHR using the MAC address of the last additional ethernet interface
remove the DHCP-Clinet config on ether0
add IP addresses & gateway & dns – or add a DHCP-Clinet config on last ethernet interface
perform the necessary license configurations you need/want.
power off the vm CHR
remove the last ethernet interface
power on the vm CHR
perform a system reset no default configuration
configure your CHR as wanted.
Note - your remaining ethernet interfaces will retain the MAC address you assigned to them when you added/created the Proxmox ethernet interfaces on your vm CHR
Another option that you might consider is to just buy a normal license key, and install regular x86 RouterOS in the VM, instead of CHR. A regular ROS license does not need to be online in order to talk to the cloud licensing server, or anything like that.
Though things were a bit different back with RouterOS 6, with version 7 the regular and “CHR” releases of RouterOS behave virtually identically to each other when running as a hypervisor guest; it’s just the licensing that is different. They support all of the same networking adapter interfaces, and will perform identically. There are only two feature disparity/differences between them that I am aware of: 1) I don’t believe non-CHR runs any of the various guest tools for different hypervisors (vmtools, qemu-ga, etc.). 2) CHR paid licenses support /ip/cloud, but regular x86 does not.
The main downside to the regular licensing model is that license keys are not transferrable once purchased and applied to a particular installation, unlike CHR keys. If you ever change to a different hypervisor engine, or touch the VM disk image in any way (try to re-size it, make any changes to the MBR, etc.), your license becomes forfeit. So if you are seriously considering this, I would make the VM disk as small as possible (ROS does not need much space), and then immediately after applying the license key, I would shut down the VM and make a backup of the disk image…that way, if you ever accidentally mess up and the license key in your running instance becomes toast, you can at least go back to a snapshot of the image where the license key was still intact, and then restore a backup of your ROS config onto that.
Thanks for the answer.
This is interesting. What I don’t know is the behavior of RouterOS: if sometimes, for some reason RouterOS needs to verify its license, what happen if Mikrotik web site is unreachable?
What I need is an official solution. I cannot just install an guess what happen, since the target installation is a customer production environment.
What is wrong with the solution of buying a normal license, instead of a CHR license? To me that makes the most sense for an “airgapped” router.
All of this is well documented by MikroTik already: link
If the “deadline-at” date is reached without successfully contacting the account server, the router will consider that the license has expired and will disallow further software updates. However, the router will continue to work with the same license tier as before.
After successful communication with the license server, the dates will be updated.
So the router will continue to function; it just won’t let you update the RouterOS version.
If you absolutely insist on using CHR instead of regular RouterOS licensing, rather than prepping the VM on one machine and then cloning it onto its final destination (and having to jump through all of the hoops to work around the system ID changes and everything), what I would do is install it on its permanent home first, hook it up to the internet temporarily, install the license, then disconnect it. The problem you will still have moving forward, though, is that every time you need to upgrade RouterOS, you will need to find a way to hook it up to the internet first in order to do it, which still makes the non-CHR license superior for this particular application, in my opinion.
I apologize for my latest post: I probably gave the impression I have no respect for the the people in this forum and for their help and patience.
I just wanted to highlight that I need a Mikrotik rock solid documentation to submit to the end user (which is the one that is paying) to demostrate that this solution is 100% legal end technically certified.
In the meantime I’ll set up a test environment in the net few days to test how the “RouterOS normal-license” solution works in the real world.