Agent Tunnel — Overview
One agent reaches TCP services across every routable part of your site network — from the local LAN to permitted VLANs and subnets — through a cheap board, a Linux box, a Windows PC or Mac you already have, or the site's own router when it runs OpenWrt, dialling out to MikRouter. No MikroTik and no port forwarding required. Start here to see how it fits together.
What is an agent?
An agent is a small program on something already sitting on your network — a cheap board, a Raspberry Pi, a Windows PC or Mac you already have, or the site's own router, if it runs OpenWrt. It calls out to MikRouter and keeps that line open, so you can reach your devices from anywhere — no port forwarding, and it still works when your internet has no public address of its own.
One agent is enough for the whole site — your router, a camera, an OLT, a DVR, a NAS, a PC. You add one mapping per device you want to open up.
Unlike the MikroTik VPN guides above, an agent needs no MikroTik at all.
What you need to start
Two things — an agent in your dashboard, and something at the site to run it on.
- 01
An agent in your dashboard
It gives you the tunnel host and token your device needs to connect.
Create one under Agents - 02
An agent device
On the site network, with internet. Raspberry Pi, Orange Pi, or any Debian or Ubuntu box counts as Linux — and a Windows PC or Mac already at the site, or a router already running OpenWrt, can be the agent itself, with no extra hardware at all.
How it works
Think of the agent as a small helper inside your network. Set it up at the site, tell it which devices to open up, and reach them from wherever you are.
- Step 01
Set up the agent device
Flash or install the agent, connect it to the site network, then set its tunnel host and token.
- Step 02
Configure the mappings
Add a mapping for each device you want to open up — router, camera, OLT, DVR, and more.
- Step 03
Open it from anywhere
Visit the subdomain address you customized. The device's familiar login page opens in your browser.
See it in action
Open your router from anywhere
Here's what a router named Home Router could look like.
Your custom address
https://home-router
Local router address
http://192.168.1.1
You customize your own subdomain. Choose an easy-to-remember device name under *.test.mikrouter.com.
Home Router
Router Web GUI
This is only a preview. Your router will use the subdomain address you customize.
What is a mapping?
A mapping is a forwarding address. You tell the agent: when someone opens home-router.test.mikrouter.com, go to 192.168.1.1, knock on door 80, and bring back what the router answers.
The address says which device; the door — its port — says what you want from it. 80 is an ordinary web page, 443 a padlocked one, 8291 Winbox.
Nothing at your site is opened up. The agent already holds a line out to MikRouter, so the page comes back the same way the agent went out.
Create a sample mapping
A mapping is one LAN service you open up. On the agent's detail page go to Mappings›New mapping and fill it in — here is a router web UI at 192.168.1.1:
Mappings
Web 0/10TCP 0/3New mapping
Device uses HTTPS — tick this if the device’s own web UI only works over https:// (usually port 443). Leave it off for the normal case.
✓Require access password — ask for your account access password before showing this device. Recommended.
Save it and the router answers at https://home-router.test.mikrouter.com from anywhere. For Winbox, SSH, or anything that is not a web page, choose TCP instead (say 192.168.1.1:8291 for Winbox) and MikRouter hands you a public port rather than a subdomain.
The host above is an example, not a real address. Your tunnel host depends on which agent server the agent connects to — always use the exact value shown on your own agent's detail page. Add one mapping per service, up to your plan's allowance.
Lock your address with an access password
Your address is on the public internet. Tick Require access password on a mapping and MikRouter asks for your account access password first — a stranger is stopped here, not at your device's own login.
home-router.test.mikrouter.com
home-router.test.mikrouter.com
Access password
Where to get this password: your MikRouter dashboard — open Agents and look for Access password. One password covers every device you protect — it is not the device’s own login.
Don’t want this step? Untick Require access password on this device’s mapping and it opens directly again.
MikRouter secure access
Set the password under Agents before you tick the box — one password covers every device you protect. Raw TCP mappings (Winbox, SSH) have no unlock page; they rely on the device's own login.
ESP32 limits
An ESP32 is cheap and low power, but tiny — about half a megabyte of memory, and one small 2.4 GHz radio carrying every byte of your tunnel. Two things follow.
1. Only a few connections at a time
Every page, image, and button on a device's web page opens its own connection. They all share the board's one radio, so only a few run at a time — the same on all four families. The agent's setup page counts these as Active streams:
- Every ESP32 — classic, S3, C6 & C3up to 6 active streams
- Linux, Windows PC, Mac & OpenWrt router64 active streams
Extras are not lost — they wait their turn, so a heavy page just loads slowly. The ESP32 number is fixed in the firmware, and a board on an older version may show a different one. The computer agents' 64 can be raised to 1024 in their settings; on an OpenWrt router 64 is the ceiling, which is far past what a router page needs.
A heavy device page can come up short. Most of it loads, one or two parts fail, and the browser says something like ERR_CONTENT_LENGTH_MISMATCH. Reload and it usually works, which is why it feels random — the device's own web page gives up while its connections wait their turn. Nothing is wrong with the board, the tunnel, or your network.
What helps
- Pick the agent server closest to the site. Distance sets the speed, not which ESP32 you buy — all four send at the same rate. Restart the board after moving it.
- Leave a few seconds between reloads.
- For a device with a heavy page, use a Linux, Windows, or Mac agent — or the router itself, if it runs OpenWrt. None of them have this limit.
2. Wi-Fi only — no network cable
An ESP32 has no LAN port — it joins over 2.4 GHz Wi-Fi, and that same radio carries your tunnel traffic, so a weak signal drops the agent. A Linux, Windows PC, or Mac agent can take a network cable instead: wired does not drop, and is faster. An OpenWrt router has no Wi-Fi to cross at all — it is already the thing the cable plugs into.
Which is right for me?
Check your router first — if it already runs OpenWrt, it can be the agent itself. Nothing extra to buy, power, or find a shelf for, and it keeps being your router: the agent does not touch the radios, DHCP, DNS, or the firewall. Set up an OpenWrt router →
Pick an ESP32 for one router page now and then, with good Wi-Fi where it sits. All four perform the same, so buy on the extras: the ESP32-S3 has the most memory, the ESP32-C6 is newest with Wi-Fi 6.
Pick a Linux agent — recommended — for several devices, daily use, or a network cable. A Raspberry Pi, Orange Pi, or any spare Debian / Ubuntu computer works. Install the Linux agent →
Use a Windows PC or Mac you already have if there is one at the site — no extra hardware, nothing else to install. Install its background service and the tunnel runs with nobody signed in. Windows → Mac →
Put your local dev server or API online
A mapping does not have to point at a router. Run the Windows, Mac, or Linux agent on your own development machine and point a mapping at 127.0.0.1 — the app you are building answers on a public HTTPS address, the way a tunnelling tool like ngrok does. The address is part of your account, so it is the same every time and does not change when you restart.
A dev server on port 3000, published as my-api.test.mikrouter.com
| Field | Value | Note |
|---|---|---|
| Kind | Web (HTTP/S) | TCP is for things that are not web pages |
| LAN host | 127.0.0.1 | the agent runs on this same computer |
| LAN port | 3000 | the port your framework prints on startup |
| Device uses HTTPS | off | tick it only if your dev server is https:// |
| Address scheme | HTTPS (recommended) | MikRouter provides the certificate |
| Subdomain | my-api | answers at my-api.test.mikrouter.com |
What it is good for
- Webhooks and callbacks. A payment gateway, GitHub, or any service that has to call you back needs a public address. Point it at the mapping and the request lands in the code running on your desk, breakpoints and all.
- Showing work in progress. Send a client or a tester a link instead of deploying a build for every change.
- Testing on real devices. Open it on a phone on mobile data, or from another office — nothing has to be on the same Wi-Fi as your computer.
- A mobile app or another service calling your API over the internet while the API is still only on your machine.
- Live reload and WebSockets keep working. Connection upgrades pass through untouched, so hot reload and socket APIs behave as they do locally.
Four things to get right
1. Let your dev server accept the public name. It is asked for my-api.test.mikrouter.com, not localhost, and several frameworks refuse a name they were not told about — the giveaway is "blocked request" or "invalid host header" instead of your page. Add the mapping's address to allowedDevOrigins (Next.js), server.allowedHosts (Vite), or ALLOWED_HOSTS (Django).
2. Check what it is listening on. 127.0.0.1 works when the agent is on the same computer as the dev server. If the agent runs on another machine — a Raspberry Pi, say — start the dev server on 0.0.0.0 so the rest of the network can reach it, and put that computer's LAN address in the mapping instead.
3. Keep it private — with one exception. An unfinished app on a public address is worth protecting, so tick Require access password as above. Do not tick it on a webhook mapping — the unlock page is a sign-in, and a payment provider cannot sign in. Leave those open and let the provider's own signature check be the guard.
4. Databases and SSH go through a TCP mapping. Postgres, MySQL, Redis, or SSH are not web pages, so choose Raw TCP and MikRouter hands you an address and port instead of a subdomain. There is no unlock page on those, so the service's own login is the only thing standing in front of it — never expose one with a weak or default password.
Use a computer agent for this — an ESP32 cannot run your code, and it holds only a few connections at a time, which a modern web page exhausts on its own. Windows → Mac → Linux →
The step-by-step guides
Pick the path that matches your device and follow it in order.
ESP32 path — three guides
- 1.Which ESP32 works with MikRouter? → — what to buy, what to avoid, and how to tell which board you have.
- 2.Flash an ESP32 → — put the agent firmware on the board over USB.
- 3.Connect ESP32 agent → — enter your Wi-Fi, tunnel host, and token on its setup page.
Linux path
1.Install Debian/Ubuntu on a Raspberry Pi → — only if the board has no operating system yet. If it already runs Debian or Ubuntu, go straight to step 3.
2.Install Debian/Ubuntu on an Orange Pi → — the same for an Orange Pi, which needs the image built for your exact board. Use whichever of these two matches the board you have.
3.Set up an agent on Linux → — one install command on a Raspberry Pi, Orange Pi, or any Debian / Ubuntu box. Nothing to flash and no setup Wi-Fi.
Desktop path — no extra hardware
1.Set up an agent on a Windows PC → — one download on a PC that is already at the site.
2.Set up an agent on a Mac → — download the app and click through it, or paste one line into Terminal.
OpenWrt path — the router is the agent
1.Set up an agent on an OpenWrt router → — one install command over SSH, on a router that already runs OpenWrt 23.05 or newer with about 600 KB of free flash.
2.Set up an agent on a small-flash OpenWrt router → — only if guide 1 says there is no room. A few kilobytes stay on flash and fetch the agent into memory at every boot.