How I Configured MikroTik for a Cryptocurrency Mining Farm — A Real-World Guide

By Gadisa Belachew — Network and Security Engineer, Addis Ababa, Ethiopia

Introduction

When I was first called in to fix the network at a cryptocurrency mining farm, the situation was already bad. ASIC miners were going offline unpredictably, and nobody could tell why. The assumption was hardware failure. But after a few hours of investigation, the real problem became clear — the monitoring systems had no reliable network connection, so overheating events were going undetected until it was too late.

That experience taught me something important: in a crypto mining environment, the network is not just infrastructure — it is the nervous system of the entire operation. If it fails, you are not just losing connectivity. You are losing visibility, losing control, and losing money with every minute that passes.

This guide is based on that real deployment. I will walk you through exactly how I configured MikroTik to solve those problems — from the initial setup through VLANs, firewall hardening, failover, and QoS — so that when I left the site, the network ran perfectly without any further intervention.

The Environment

Before diving into configuration, it helps to understand what we were working with:

• Site type: Cryptocurrency mining farm running ASIC miners
• Internet sources: Primary fiber optic connection with a microwave/radio link as backup
• Key problem: Unstable connectivity during peak hours was causing monitoring systems to lose visibility over miner temperatures — leading to undetected overheating events
• Goal: Build a network that was stable, segmented, secure, and fully manageable remotely

Prerequisites

Before you begin, make sure you have the following ready:

• A MikroTik router (I used a CCR series for this deployment)
• A PC or laptop with an ethernet port
• WinBox downloaded from mikrotik.com
• Physical access to the router for initial setup
• Your ISP credentials for the WAN interface
• A clear network diagram of your device layout

Phase 1 — Initial MikroTik Setup

The first rule I follow on every deployment: never touch configuration before the router is updated and secured. Skipping this step is how you inherit someone else's security problems.

Step 1 — First Login

Connect your laptop directly to the MikroTik router using an ethernet cable on ether1. Open WinBox and log in using the default credentials:

• IP Address: 192.168.88.1
• Username: admin
• Password: (leave blank)

Step 2 — Update RouterOS Immediately

Before any configuration, update the operating system. I have seen routers in mining environments running RouterOS versions that were years out of date — these carry known vulnerabilities that are actively exploited.

System > Packages > Check for Updates > Update

Reboot the router after the update completes before proceeding.

Step 3 — Change Default Credentials

Default credentials are the number one entry point for unauthorized access. I change these within the first five minutes of every deployment — no exceptions.

System > Users > admin > Change Password

Use a strong password of at least 16 characters. I also create a separate read-only account for monitoring purposes so that anyone checking network stats does not need the admin password.

Phase 2 — Network Design

The biggest mistake I see in mining farm networks is everything running on a flat network — miners, cameras, staff laptops, and monitoring systems all sharing the same broadcast domain. This creates two problems: a security risk if any device is compromised, and a performance problem when staff traffic competes with miner traffic.

The solution is VLAN segmentation. Here is the structure I used for this deployment:

Separating the monitoring systems onto their own VLAN was specifically important in this case. Because monitoring had previously shared the network with everything else, congestion during peak hours was causing monitoring packets to drop — which is exactly why the overheating events went undetected. Isolating monitoring traffic on VLAN 40 ensured it always got through regardless of what else was happening on the network.

Phase 3 — Configuring VLANs on MikroTik

Create the VLANs

'''bash
/interface vlan
add name=vlan10-miners vlan-id=10 interface=ether2
add name=vlan20-mgmt vlan-id=20 interface=ether2
add name=vlan30-ops vlan-id=30 interface=ether2
add name=vlan40-monitoring vlan-id=40 interface=ether2
'''

Assign IP Addresses to Each VLAN

'''bash
/ip address
add address=10.10.10.1/24 interface=vlan10-miners
add address=10.10.20.1/24 interface=vlan20-mgmt
add address=10.10.30.1/24 interface=vlan30-ops
add address=10.10.40.1/24 interface=vlan40-monitoring
'''

Configure DHCP for Each VLAN

'''bash
/ip pool
add name=pool-miners ranges=10.10.10.10-10.10.10.254
add name=pool-ops ranges=10.10.30.10-10.10.30.254
add name=pool-monitoring ranges=10.10.40.10-10.10.40.254

/ip dhcp-server
add name=dhcp-miners interface=vlan10-miners address-pool=pool-miners
add name=dhcp-ops interface=vlan30-ops address-pool=pool-ops
add name=dhcp-monitoring interface=vlan40-monitoring address-pool=pool-monitoring
'''

Phase 4 — WAN Setup and Failover

This was one of the most critical parts of the deployment. The farm had two internet connections available — a primary fiber optic link and a microwave/radio link as backup. The problem before I arrived was that failover was not configured, so when the fiber dropped during peak hours, the entire operation lost connectivity manually until someone noticed and switched cables by hand.

MikroTik makes automatic failover straightforward using route distance values:

'''bash
/ip route
add dst-address=0.0.0.0/0 gateway=fiber-gateway distance=1
add dst-address=0.0.0.0/0 gateway=microwave-gateway distance=2
'''

A lower distance value means higher priority. MikroTik automatically switches to the microwave link the moment it detects the fiber gateway is unreachable — with no manual intervention required. When fiber recovers, it switches back automatically.

I also configured a netwatch script to actively monitor the WAN and trigger failover faster than the default route checking interval:

'''bash
/tool netwatch
add host=8.8.8.8 interval=10s \
down-script="/ip route set [find gateway=fiber-gateway] distance=3" \
up-script="/ip route set [find gateway=fiber-gateway] distance=1"
'''

This checks connectivity every 10 seconds and adjusts route distances dynamically — significantly faster than waiting for the default routing protocol to detect a failure.

Phase 5 — Firewall and Security Hardening

A cryptocurrency mining farm is a high-value target. The equipment alone is worth significant money, and unauthorized access to the network could mean someone else controlling your miners or stealing your hash power. I applied the following firewall rules as a baseline:

Core Firewall Rules

'''bash
/ip firewall filter

Drop all invalid connections immediately

add chain=input connection-state=invalid action=drop comment="Drop invalid"

Allow established and related connections

add chain=input connection-state=established,related action=accept \
comment="Allow established"

Isolate monitoring VLAN — only allows outbound alerts, no inbound

add chain=forward src-address=10.10.40.0/24 \
dst-address=!10.10.10.0/24 action=accept \
comment="Monitoring can reach miners only"

Prevent operations VLAN from reaching miners directly

add chain=forward src-address=10.10.30.0/24 \
dst-address=10.10.10.0/24 action=drop \
comment="Staff cannot access miner VLAN"

Restrict router management to management VLAN only

add chain=input src-address=10.10.20.0/24 action=accept \
comment="Management VLAN can access router"
add chain=input action=drop comment="Drop everything else"
'''

Disable All Unused Services

Every open service is a potential attack surface. I disable everything that is not actively needed:

'''bash
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set api disabled=yes
set api-ssl disabled=yes
set ssh port=2222
'''

Only SSH on a non-standard port and WinBox remain active for remote management.

Phase 6 — QoS and Bandwidth Management

Before I configured QoS, staff devices on the operations VLAN were consuming significant bandwidth during shift changes — people streaming, downloading, and browsing — which caused noticeable latency on the miner traffic. In a crypto mining context, even small amounts of additional latency on pool communication can affect mining efficiency.

Prioritize ASIC Miner Traffic

'''bash
/ip firewall mangle
add chain=prerouting src-address=10.10.10.0/24 \
action=mark-packet new-packet-mark=miners-traffic \
comment="Mark all miner traffic"

/queue tree
add name=miners-priority packet-mark=miners-traffic \
priority=1 max-limit=100M \
comment="Miners get highest priority"
'''

Limit Staff Bandwidth

'''bash
/queue simple
add name=ops-limit target=10.10.30.0/24 \
max-limit=20M/20M \
comment="Cap staff VLAN at 20Mbps"
'''

This ensures that regardless of how many staff devices are active, the ASIC miners always have the bandwidth they need for pool communication and monitoring.

Phase 7 — Monitoring and Alerts

Given that the original problem was undetected overheating due to poor monitoring visibility, setting up reliable network-level alerts was a priority.

Enable SNMP

'''bash
/snmp
set enabled=yes \
contact="gadisa@miningfarm.com" \
location="Crypto Farm — Server Room A"
'''

I connected SNMP to The Dude (MikroTik's free monitoring tool) running on a local server. This gave real-time visibility into interface utilization, link status, and device availability across all VLANs.

Configure Automatic Email Alerts

'''bash
/tool e-mail
set server=smtp.gmail.com port=587 \
from=alerts@miningfarm.com \
user=alerts@miningfarm.com \
password=yourpassword

/system script
add name=wan-failover-alert source={
:local msg "PRIMARY WAN DOWN — Switched to Microwave Backup"
/tool e-mail send to="admin@miningfarm.com" \
subject="NETWORK ALERT — Mining Farm" body=$msg
}
'''

With this in place, the network administrator receives an immediate email the moment the primary fiber link goes down — even at 3am when no one is physically on site.

Phase 8 — Backup and Remote Management

Schedule Automatic Configuration Backups

Losing your router configuration at a remote site without a backup is a serious problem. I scheduled weekly automatic backups as a baseline:

'''bash
/system backup save name=("crypto-farm-backup-" . \
[/system clock get date])
/export file=("crypto-farm-config-" . \
[/system clock get date])
'''

Store these backups off-site — either on a cloud storage service or a remote server.

Remote Access via VPN Only

Never expose WinBox or SSH directly to the public internet. For this deployment I configured an IPsec VPN tunnel so that all remote management traffic passes through an encrypted tunnel before reaching the router. This means even if someone intercepts the traffic, they cannot read or manipulate it.

Results After Deployment

Once the configuration was complete and tested, the results were immediate and measurable:

• Zero undetected overheating events — monitoring traffic on its dedicated VLAN reached the alert system reliably
• Automatic failover working — when fiber experienced drops during peak hours, the microwave link took over within 10 seconds with no manual intervention
• Miner uptime improved significantly — stable connectivity meant ASIC miners stayed connected to mining pools without interruption
• Staff bandwidth no longer competed with miner traffic thanks to QoS rules

The configuration has been running without issues since deployment.

Deployment Checklist

Use this checklist for your own mining farm deployment:

• RouterOS updated to latest stable version
• Default credentials changed on first login
• VLANs created and tested for isolation
• Monitoring systems on dedicated VLAN
• Dual WAN failover configured and tested
• Netwatch active monitoring configured
• Firewall rules applied and verified
• All unused services disabled
• QoS rules prioritizing miner traffic
• Staff bandwidth capped
• SNMP monitoring enabled
• Email alerts configured and tested
• Automatic config backups scheduled
• Remote access via VPN only

Conclusion

Configuring a network for a cryptocurrency mining farm is different from a typical office or data center deployment. The stakes are higher, the environment is more demanding, and the consequences of downtime are immediate and financial.

The most important lesson from this deployment was that monitoring systems must be treated as critical infrastructure — not an afterthought. By isolating monitoring traffic onto its own VLAN and ensuring it always had priority network access, we solved the root cause of the overheating problem that had been affecting the farm for months before I arrived.

MikroTik proved to be an excellent fit for this environment. The combination of flexible VLAN support, reliable failover routing, granular firewall rules, and built-in QoS made it possible to solve every challenge this deployment presented — at a fraction of the cost of enterprise alternatives.

If you are planning a similar deployment, start with the checklist above and adapt the configurations to your specific hardware layout and internet sources. Every mining farm is different, but the core principles covered in this guide apply universally.

Gadisa Belachew is a Network and Security Engineer based in Addis Ababa, Ethiopia, with over 8 years of experience in networking, security, and infrastructure deployment.

Tags: #networking #mikrotik #security #devops #cryptocurrency

Author's Note: This article is written from my direct hands-on experience configuring MikroTik in a real cryptocurrency mining environment. All configurations have been tested in production.