Ignix + MikroTik

RouterOS already sees the traffic.
Someone should be reading it.

Ignix is the oversight layer for RouterOS traffic-flow. The router stays the router — no subscription on the box, no replacement for WinBox, no agents on endpoints. We take the telemetry RouterOS already produces, bring it over WireGuard, and pay attention every day.

hello@ignix.co.uk

The path

One feed. Encrypted. Metadata only. Nothing in the data path.

RouterOS

RB5009, CCR, hEX, CHR — the box you already chose

↓

IP traffic-flow

NetFlow v9 / IPFIX — who talked to whom, ports, bytes, duration

↓

Ignix collector

On the router itself, or a small Ubuntu VM / Pi on the LAN

↓

WireGuard

Native in RouterOS 7. Telemetry never exported to the open internet

↓

Ignix Security Cloud

EU data plane — nfcapd per site, context, DHCP names

↓

Daily attention

AI-assisted analyst · morning report · evening update · portal

Why this pairing exists

People pick MikroTik because RouterOS delivers serious routing capability without recurring per-device subscriptions, and because the CLI is a real operating system. Then the customer asks who is watching the network — and too often the answer is “buy a UTM instead.”

No license on the router

RouterOS does not charge you every year to keep routing. Ignix does not put a license on the box either. The service sits on traffic-flow. If you stop Ignix, the RB5009 is still the RB5009.

The CLI stays yours

We enable traffic-flow and, optionally, DHCP syslog. We do not take WinBox away, wrap RouterOS in a proprietary overlay, or ask anyone to stop using the CLI they actually like.

The telemetry is already there

IP traffic-flow is built in. WireGuard is built in on v7. DHCP syslog is built in. The missing piece is not another feature on the router — it is someone competent reading what it already emits.

Keeps RouterOS in the stack

When an SME wants “visibility,” the default pitch is Forti / UniFi / a licensed UTM. Ignix is the overlay that lets the MikroTik stay the edge.

What the customer actually gets

Same service on every RouterBOARD that can export traffic-flow. The hardware only changes how we attach.

Device	Typical site	How Ignix attaches
hEX / RB4011	Small office	traffic-flow to a Pi or Ubuntu VM on the LAN. Router stays the router.
RB5009	Professional office, multi-VLAN retail	Either the RB5009 is the WireGuard peer, or it exports to a local collector. Live in production.
CCR2004 / CCR2116	Busy edge, higher flow volume	Same recipe; collector beside the CCR is the usual choice so the router is not also the tunnel endpoint for telemetry.
CHR	Lab / cloud	Identical path. Useful for proving the feed before a hardware cutover.

Included

Morning report and evening update, in English
Portal at portal.ignix.co.uk
Ask Ignix — questions against live flow data
Device names from MikroTik DHCP syslog, where enabled
Alerts when something genuinely needs a look

Not included — on purpose

Replacing WinBox, The Dude, or your CLI
Packet capture or sitting in the data path
A SIEM project
Endpoint agents
Us managing RouterOS for you

Two shapes that already run

We do not pretend every site looks the same. Both of these are live.

Shape A — router as peer

RB5009 owns the tunnel

Multi-VLAN site. RouterOS already does DHCP, firewall, WireGuard and traffic-flow. The RB5009 is the Ignix mesh peer. Fits restaurants, retail, and any site where the MikroTik already is the network.

RouterOS
  traffic-flow + WireGuard
        → Ignix EU

Shape B — collector beside the router

Router exports, VM tunnels

Professional office. MikroTik stays LAN gateway, DHCP and firewall. NetFlow lands on a small Ubuntu VM; the VM holds WireGuard. Decouples telemetry from the router as a single point of failure.

RouterOS  →  Ubuntu collector
                  WireGuard
                      → Ignix EU

What we turn on

This is the whole on-router change for Shape B. Target address is the collector on the LAN — never a public IP.

RouterOS — IP traffic-flow

# export NetFlow v9 to the local collector
/ip traffic-flow set enabled=yes interfaces=all
/ip traffic-flow target add dst-address=192.168.0.20 port=2055 version=9

RouterOS — DHCP names (optional, worth it)

# lease events only — exclude packet debug or the receiver drowns
/system logging action set [find name=remote] remote=10.100.0.1 remote-port=514
/system logging add topics=dhcp,!debug,!packet action=remote

Shape A is the same traffic-flow, with the target on the WireGuard mesh instead of a LAN VM. We do not ask sites to export NetFlow to the open internet.

RouterOS already sees the traffic.Someone should be reading it.