CHR for RouterOS testing
Testing a new route or firewall should not require introducing lab DHCP or routes into the company LAN. CHR runs RouterOS as a virtual machine. Here it sits in Workstation between a NAT WAN and a host-only LAN, allowing a test client to use the router in an isolated network.
Image and VM resources
Use CHR v7 and a Workstation build compatible with the host. Record both builds for reproducible tests.
This lab allocates 2 vCPUs, 1 GiB RAM, at least 1 GiB disk and two vNICs. Actual throughput depends on host resources and licensing.
Obtain the official MikroTik VMDK and access to Virtual Network Editor. Perform initial configuration through the console and change the administrator password before network access.
License throughput limits
Free licensing limits upload to 1 Mbps per interface. P1, P10 and P-Unlimited have different limits. Desktop Workstation is not an HA router design.
Map vNICs to router interfaces
Map each virtual NIC before assigning addresses: compare its VMnet and MAC with the router's interface output. Workstation adapter order does not guarantee the ether1/ether2 mapping. Once mapped, the client uses CHR as its gateway and the router NATs traffic towards the lab WAN.
Lab WAN and LAN topology
Connect ether1 to NAT and ether2 to host-only, with a client VM on the LAN. Disable VMware DHCP on that LAN when CHR or another service will manage it.
Keep the lab isolated
Do not bridge lab VMnets to the company NIC. Use unique credentials and disable unused management services. Snapshots contain credentials and require sensitive-backup controls. The example firewall covers IPv4 only.
Create the VM and configure the IPv4 lab
Start the VM with MikroTik's official VMDK. Compare a publisher checksum when available and record a local hash. Select Existing Virtual Disk in the new VM, then compare NIC MACs through the console with the WAN/LAN plan before configuring the interfaces.
Sample WAN is 192.168.100.10/24 via 192.168.100.2, with LAN 10.99.0.1/24. Obtain actual subnet, gateway and DNS from Virtual Network Editor and replace example values.
/interface ethernet print detail
/user set [find name=admin] password="REPLACE_WITH_UNIQUE_ADMIN_SECRET"
/system identity set name=CHR-STAGING
/ip address add address=192.168.100.10/24 interface=ether1 comment="LAB WAN"
/ip address add address=10.99.0.1/24 interface=ether2 comment="LAB LAN"
/ip route add dst-address=0.0.0.0/0 gateway=192.168.100.2
/ip dns set servers=192.168.100.2 allow-remote-requests=no
/ip firewall filter add chain=input connection-state=established,related action=accept
/ip firewall filter add chain=input in-interface=ether2 src-address=10.99.0.0/24 action=accept
/ip firewall filter add chain=input action=drop
/ip firewall filter add chain=forward connection-state=established,related action=accept
/ip firewall filter add chain=forward in-interface=ether2 out-interface=ether1 action=accept
/ip firewall filter add chain=forward action=drop
/ip firewall nat add chain=srcnat src-address=10.99.0.0/24 out-interface=ether1 action=masquerade
/ping 192.168.100.2 count=3
/system license printRules target a fresh IPv4 lab. Restrict IPv6 separately. Test the gateway and a client using 10.99.0.1 plus valid DNS. SSH/WinBox must remain inaccessible from WAN.
Restrict management services on the isolated lab
After the original fresh-lab firewall and an independent console test, restrict SSH/WinBox to the actual lab LAN and disable unused legacy management services. These commands modify service admission, so verify a new LAN session before closing the old one. Replace the sample subnet; do not apply to a router whose management arrives through WAN.
/ip service set ssh address=10.99.0.0/24
/ip service set winbox address=10.99.0.0/24
/ip service set telnet disabled=yes
/ip service set ftp disabled=yes
/ip service set www disabled=yes
/ip service set api disabled=yes
/ip service set api-ssl disabled=yes
/ip service printExpected: only approved management services remain enabled with the scoped address. A restricted service does not create a firewall allow. A new management timeout requires checking both service address and input rules through the console.
Measure throughput and resource use
During throughput tests, record host/CHR CPU and drop counters. Attach the license tier to the result. Distinguish Free-license limits from CPU shortages.
Verify forwarding from a client, not only router ping
/ip address print detail
/ip route print detail
/ip firewall nat print stats
/ip firewall filter print stats
/interface ethernet print stats
/system resource print
/export file=chr-accepted-labTest from the client VM: check its LAN address, gateway 10.99.0.1 and resolver, then request an allowed service. Forward and NAT counters should rise for a fresh connection. A ping originating on the router takes a different processing path and does not prove client forwarding. Compare interface drops, CPU and license when investigating speed, and download the export out of the VM into protected storage.
Unreachable gateways or low throughput
For a gateway that does not respond, start with connectivity: check Connected at power on, MAC mapping, VMnet and subnet. A static setup will not acquire addresses through DHCP. Then check the client's gateway and DNS. For low throughput, inspect the license and host load; the default route must point to the NAT network gateway, not CHR's own address.
Snapshots and off-VM exports
Take a pre-test snapshot and keep exports outside the VM. A snapshot does not survive host-storage loss independently. After cloning, check IP, system ID and license requirements. Never start duplicate-IP VMs together.
What the lab establishes
Use the lab to check syntax and configuration behavior. Do not generalize Workstation throughput or reliability to RouterBOARD or production hypervisors.
Best Practices
- Version-control configuration and review changes.
- Use least privilege and explicit allow-lists.
- Automate repeatable checks and monitor the expected state.
- Test upgrades and restores before production rollout.
Conclusion
A reliable implementation of Install MikroTik CHR on VMware Workstation is more than a successful first run. Keep the configuration documented, observable, recoverable, and aligned with the team's change-management process.
Frequently Asked Questions
Can a Workstation lab replace a production router?
No. It validates configuration. HA, support and capacity require separate design.
Why is throughput low?
Check both the CHR license tier and host resources.
