Hardening the MikroTik Chateau — security, DoH, monitoring

After the base setup works, the next pass is security and observability. Things that aren't strictly needed on day one but hurt when you skip them.

1. Security hardening — MikroTik

Default config is fine for a LAN-only router behind CGNAT, but if the Chateau ever gets a public IP (static IP from the ISP, different provider, travel), an unhardened router is a liability. Do this once, doesn't take long.

Disable services you don't use

/ip service print
/ip service disable telnet,ftp,api,api-ssl,www
/ip service print where disabled=no

Keep only ssh and winbox (and www-ssl if you use WebFig — better via SSH tunnel). Everything else is attack surface for nothing in return.

Restrict admin access to LAN + BTH only

/ip service set ssh address=192.168.50.0/24,192.168.216.0/24
/ip service set winbox address=192.168.50.0/24,192.168.216.0/24

The 192.168.216.0/24 is the BTH peer range — so you can still manage the router via Back To Home from outside.

Change the SSH port

/ip service set ssh port=22022

Not security by itself (port scanners find anything), but cuts the volume of automated bot login attempts by ~95%.

Strong admin password + separate daily-use user

/user set admin password="long-random-string"
/user add name=daily group=full password="different-long-random-string"

Use daily for daily logins; admin becomes break-glass. If either account is ever compromised, you still have the other to get in.

Firewall — drop WAN-input by default

Default config usually has it, but verify:

/ip firewall filter print

You want something like:

0  chain=input action=accept connection-state=established,related,untracked
1  chain=input action=drop connection-state=invalid
2  chain=input action=accept protocol=icmp
3  chain=input action=accept in-interface-list=LAN
4  chain=input action=drop in-interface-list=WAN

If the last rule (drop from WAN) is missing → add it. Otherwise services bound to 0.0.0.0 are reachable from the internet.

2. DNS over HTTPS

Hides DNS queries from the ISP (the carrier sees that you browse but not what). One command on MikroTik:

/ip dns set use-doh-server=https://cloudflare-dns.com/dns-query verify-doh-cert=yes
/ip dns set servers=""
/ip dns cache flush

Confirm:

/ip dns print

Should show use-doh-server=https://cloudflare-dns.com/dns-query and a non-zero doh-max-server-connections.

Gotchas:

Chateau needs to reach cloudflare-dns.com via HTTPS before DoH can resolve anything — cert verification bootstrap. Usually fine.
Mixing plain + DoH is allowed: /ip dns set servers=1.1.1.1,8.8.8.8 use-doh-server=... — servers becomes fallback.
Doesn't affect downstream devices using their own DNS (phones with private DNS set to one.one.one.one, etc.).

3. Monitoring + alerting on WAN changes

Useful if you want to know when ether1 flaps to LTE — can mean upstream problems worth debugging, or a brief ISP glitch.

Netwatch with log + script hooks

/tool netwatch add host=1.1.1.1 type=simple interval=30s timeout=2s \
  down-script="log error \"ether1 failover triggered\""  \
  up-script="log warning \"ether1 recovered\""

Telegram alert (no external infra)

Create a Telegram bot via @BotFather, note the token + your chat ID, then:

/system script add name=notify-down source={
  /tool fetch url="https://api.telegram.org/bot<TOKEN>/sendMessage" \
    http-method=post http-header-field="Content-Type:application/json" \
    http-data="{\"chat_id\":\"<CHAT_ID>\",\"text\":\"🔴 ether1 down — failed over to LTE\"}" \
    keep-result=no mode=https
}
/system script add name=notify-up source={
  /tool fetch url="https://api.telegram.org/bot<TOKEN>/sendMessage" \
    http-method=post http-header-field="Content-Type:application/json" \
    http-data="{\"chat_id\":\"<CHAT_ID>\",\"text\":\"🟢 ether1 recovered\"}" \
    keep-result=no mode=https
}
 
/tool netwatch add host=1.1.1.1 type=simple interval=30s timeout=2s \
  down-script="/system script run notify-down" \
  up-script="/system script run notify-up"

LTE data usage — manual

LTE plan (unlimited) has fair-use throttling after ~60 GB/day. Current counters:

/interface print stats where name=lte1
/interface monitor-traffic lte1

LTE plan app shows plan-level usage; MikroTik counters are interface-level.

4. Power-loss & reboot behavior

What happens when the power goes out and comes back.

MikroTik Chateau on cold boot:

Config restores from flash, interfaces come up in order.
ether1 DHCP client needs upstream to be up; in practice upstream usually beats Chateau.
LTE registration takes ~30–90s after boot. During that window failover routes activate automatically — 1.1.1.1 probe fails while ether1 DHCP negotiates, so traffic briefly uses LTE until ether1 recovers. Harmless.

Raspberry Pi gateway on cold boot (if you use one for corporate VPN):

Pi boots, eth0 gets its reserved IP, VLAN interface comes up.
dnsmasq + iptables + routing restore automatically via systemd + iptables-persistent.
The VPN tunnel does NOT auto-start — by design, because it needs a fresh TOTP. Work SSID clients get DHCP + the kill-switch keeps their internet off until the tunnel is reconnected manually.

If you have a UPS, 10–15 min of runtime covers most outages without any manual step.

5. RouterOS upgrade strategy

Upgrades occasionally break things — LTE firmware regressions on the RG650E have been a theme on the MikroTik forum. Be deliberate.

Safe flow:

Check what's available:

/system package update check-for-updates

Keep the current version's downgrade package before upgrading — lets you roll back without TFTP:
```
/system package downgrade
```
Don't run this without having the prior .npk in /file.
Back up first.
Stable channel only — stay on long-term or stable, never development / testing.
Upgrade:
```
/system package update install
```
Router reboots. 2–3 min downtime.

After upgrade, check LTE still works:

/interface lte monitor lte1 once
/ping 1.1.1.1 interface=lte1 count=4

When to upgrade:

Security advisories on help.mikrotik.com — upgrade soon.
New features you actually need.
Never upgrade blind on a weekend if you rely on the router for work — wait for a window where rollback is tolerable.

6. Lower-priority ideas for later

Guest WiFi on separate VLAN

Same pattern as any isolated SSID: virtual AP + separate PVID + VLAN table entry. MikroTik as L3 gateway directly. Useful for visitors without exposing the main LAN (no printer, no NAS, no smart-home devices visible).

Scheduled auto-reboot

/system scheduler add name=weekly-reboot start-date=sep/01/2026 start-time=04:00:00 \
  interval=7d on-event="/system reboot"

Weekly reboot catches memory leaks on LTE firmware (a known RG650E issue).

DHCP reservations

Static IPs for NAS / printer / smart-home by MAC. No more "wait, what IP did the NAS get".

Ad-blocking via DNS

Import a block list (pi-hole / StevenBlack's hosts) into /ip dns static. Works for every device on the LAN, no per-device setup.

Simple queues / QoS

If someone streaming 4K causes VoIP to stutter on LTE:

/queue simple add name=voip target=192.168.50.100/32 max-limit=10M/10M priority=1/1

Only worth setting up if you see real contention.

Commercial VPN client (Mullvad / Proton / etc.)

WireGuard client on the router, policy-route a specific SSID or subnet through it. Whole-LAN VPN without per-device config.

IPv6

Chateau can get IPv6 from your LTE ISP (PD-prefix). Adds a day of config and testing. Useful for dual-stack apps that prefer v6 and for some inbound use cases. Downside: more surface area to secure.

External syslog / Grafana

Ship MikroTik + Pi logs to a home Grafana/Loki/Promtail stack. Useful if you want graphs of failover events correlated with user complaints. Overkill for most home setups.

Status: some of this is live on my setup (security hardening, DoH, Telegram alerts); the rest is a backlog I work through when time allows.

RouterOS: 7.19.5 · Hardware: Chateau 5G R17 AX