@usex/mikrotik-mcp 4.7.0 → 4.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usex/mikrotik-mcp",
-  "version": "4.7.0",
+  "version": "4.8.0",
   "description": "MCP server for MikroTik RouterOS — 780+ tools over SSH for firewall, NAT, routing, DHCP, DNS, WireGuard, wireless, QoS and more.",
   "keywords": [
     "ai",

package/prompts/security-hardening-sweep.md

@@ -0,0 +1,132 @@
+---
+name: security-hardening-sweep
+title: Security hardening sweep (pick device → audit → fix by finding)
+description: Discover the configured MikroTik devices, let the user choose which one to harden, then run the granular Security Hardening suite — per-category, evidence-based findings with a stable finding_id — and remediate only the findings the user approves, safely (snapshot + Safe Mode).
+arguments:
+  - name: device
+    description: Which configured device to harden (its config key or friendly label from list_mikrotik_devices). Omit to discover the devices and let the user choose.
+    required: false
+  - name: categories
+    description: Comma-separated category slugs to scope the sweep (e.g. "firewall_default_deny,dns_resolver_exposure"). Omit to let the user pick a hardening goal (All / DDoS / port-scanning / remote-management / …), which you translate into these slugs.
+    required: false
+---
+
+You are running a **granular, evidence-based security hardening sweep** on a
+MikroTik RouterOS device managed by this MCP server. This server may manage
+**several routers**, so you MUST establish which one to harden before touching
+anything. Unlike a scored compliance grade, this suite finds each specific
+misconfiguration, gives it a stable `finding_id`, and lets you remediate
+**exactly the findings the user approves — one at a time, by ID.** Work safely:
+pick the device, audit, present findings, and never write without explicit approval.
+
+Requested device: {{device}}
+Categories to scope: {{categories}}
+
+Follow this workflow:
+
+0. **Discover devices and confirm the target (do this FIRST, always).**
+   - Call `list_mikrotik_devices` to enumerate every configured router — its
+     config key, friendly label, transport target (host/MAC), and which is the
+     default.
+   - **If `{{device}}` was provided**, resolve it against that inventory. If it
+     doesn't match a known key or label, STOP and show the user the available
+     devices so they can correct it — never guess or substitute a similar name
+     (these are different physical routers).
+   - **If `{{device}}` was NOT provided**, present the inventory as a short list
+     and **ask the user which device they want to harden.** Do not proceed to the
+     audit until they choose. If exactly one device is configured, name it and
+     confirm before continuing.
+   - Once chosen, pass that device on **every** subsequent tool call via the
+     `device` argument (audit, apply, snapshot, and verify calls all target the
+     same router). State plainly which device you are operating on.
+
+0.5 **Choose WHAT to harden (do this before the audit).**
+
+- **If `{{categories}}` was provided**, use those slugs directly and skip the menu.
+- **Otherwise, offer the user a plain-language goal menu** and let them pick one
+  or more. Then translate their choice into the category slugs below and pass
+  them as the `categories` argument to the audit. Suggested menu:
+
+| Goal (what to say to the user)                                                               | Category slugs to audit                                                                             |
+| -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| **Everything** (full hardening pass)                                                         | _(omit `categories` — runs all 12)_                                                                 |
+| **DDoS protection** (enforce populated DDoS lists, SYN-cookies, close open resolver)         | `address_list_enforcement`, `firewall_default_deny`, `kernel_ip_hardening`, `dns_resolver_exposure` |
+| **Prevent port scanning** (nmap etc. — enforce scanner detection lists, close the perimeter) | `address_list_enforcement`, `firewall_default_deny`                                                 |
+| **Lock down remote management** (brute-force ladders, exposed services, the Winbox trap)     | `firewall_default_deny`, `ip_service_exposure`, `ssh_hardening`, `management_plane_exposure`        |
+| **Close open/unused services** (telnet, reverse-proxy, unused conntrack helpers)             | `ip_service_exposure`, `connection_tracking_helpers`, `management_plane_exposure`                   |
+| **Anti-spoofing / kernel hardening** (rp-filter, source-route, redirects)                    | `kernel_ip_hardening`                                                                               |
+| **IPv6 safety** (forwarding with no filter)                                                  | `ipv6_firewall_baseline`, `kernel_ip_hardening`                                                     |
+| **DNS resolver safety** (open-resolver / amplification)                                      | `dns_resolver_exposure`                                                                             |
+| **Account & credential hygiene** (password policy, stray accounts)                           | `account_hygiene`                                                                                   |
+| **Certificate hygiene** (CRL checking)                                                       | `certificate_hygiene`                                                                               |
+| **Network segmentation review** (flat L2, servers + clients share a domain)                  | `network_segmentation`                                                                              |
+
+- Present these as a short numbered list (goal + one-line "what it covers"), ask
+  the user to choose, and confirm the resulting slug set before auditing. The
+  user may combine goals — union the slugs.
+- **Scope caveat — enforcement vs. detection.** This suite _enforces_ protections
+  the config already implies (e.g. it turns an existing-but-unblocked
+  `port scanners` / `ddoser` address-list into an active drop, and closes an open
+  resolver). It does NOT create brand-new detection rules. If the user wants to
+  _add_ fresh DDoS rate-limiting or port-scan (`psd`) detection where none exists,
+  point them to `harden_firewall` (Security Shield: `ddos_conn_limit`, `syn_flood`,
+  `port_scan` presets) and run this sweep afterwards to confirm the new lists are enforced.
+
+1. **Audit (read-only).** Call `run_security_hardening_audit` with
+   `device=<chosen device>` and `categories=<the slugs from step 0.5>` (omit
+   `categories` for a full pass). It covers firewall default-deny, address-list
+   enforcement, kernel IP hardening, IPv6 baseline, SSH, IP service exposure,
+   connection-tracking helpers, management-plane exposure, account hygiene,
+   certificate CRL policy, network segmentation, and DNS resolver exposure, and
+   returns one severity-ranked report. This is pure read: no confirmation needed.
+
+2. **Present the findings.** Organize by severity (critical → low). For each
+   finding, show:
+   - the `finding_id`, category, and severity;
+   - the **confidence**: `proven` (settled by static config) vs
+     `needs_live_verification` (latent, or dependent on runtime chain/NAT
+     interaction). Call these out separately — never present a speculative finding
+     with the same certainty as a proven one.
+   - the exact target (`.id`/rule signature), the current value, and the proposed
+     action;
+   - whether it has an automated fix or is **manual-review only** (e.g. suspicious
+     accounts, group policy, and network segmentation are never auto-applied).
+
+3. **Note the two special cases.**
+   - **IPv6 baseline (4.4)** surfaces as two _mutually-exclusive_ options with
+     distinct finding_ids — bootstrap a safe IPv6 filter, or disable IPv6
+     forwarding. Help the user pick exactly one; do not apply both.
+   - **Disabled-enforcement drop (the Winbox trap)** — re-enabling a deliberately
+     disabled drop is a separate finding_id from inserting a new default-deny.
+     Confirm the admin didn't disable it on purpose before re-enabling.
+
+4. **Plan the remediation (with user approval).** Once the user chooses which
+   findings to fix, preview first. Call `apply_security_hardening_fixes` with
+   `device=<chosen device>`, the chosen `finding_ids`, and `confirm` omitted/false
+   — this returns a **dry run** of the exact commands in safe apply order
+   (default-deny and address-list enforcement before service exposure before
+   helpers/hygiene). Per-category tools (`add_firewall_default_deny`,
+   `enforce_address_list_blocking`, `harden_kernel_ip_settings`,
+   `harden_ssh_service`, `harden_dns_resolver_exposure`, `fix_password_policy`, …)
+   offer the same dry-run preview for a single category — pass `device=` on those too.
+
+5. **Apply (only with explicit approval).** Re-issue the call with `device=<chosen
+device>` and `confirm=true`. The tool captures a pre-change **snapshot** (returns
+   a `snapshot_id`), wraps any lockout-risky change in **Safe Mode** (auto-reverts
+   if your session drops), applies each finding's fix, and commits. Report the
+   per-finding results, the `snapshot_id`, and the device it ran on.
+
+6. **Verify.** Re-run `run_security_hardening_audit` on the same `device=` to
+   confirm the applied findings no longer appear (the suite is idempotent — a
+   re-run of a fixed finding is a no-op). If anything looks wrong, roll back with
+   `diff_config_snapshots device=<chosen device> from=<snapshot_id> to=live` and the
+   snapshot tools.
+
+Finish with a short prioritized checklist (Critical / Recommended / Optional /
+Manual-review) and the exact `finding_id`s and tool calls for each tier — each
+call carrying the `device` argument. Never pass a blanket "fix everything" request
+— always remediate explicit finding_ids the user approved on the chosen device.
+If the user wants to harden **more than one** router, repeat this whole workflow
+per device (each has its own findings, snapshot, and Safe-Mode session); do not
+mix finding_ids across devices. For a scored A+–F posture grade instead, use
+`run_compliance_audit`; for shadowed/broad/dead-rule analysis, use `firewall_audit`.

package/prompts/setup-eoip-tunnel-between-sites.md

@@ -0,0 +1,119 @@
+---
+name: setup-eoip-tunnel-between-sites
+title: Build an EoIP (Layer-2) tunnel between two MikroTik devices
+description: Configure BOTH routers of an EoIP site-to-site tunnel — a bridgeable Ethernet-over-IP link that puts two sites on the SAME L2 broadcast domain — with matching tunnel-id, bridging, MTU/MSS, and (recommended) IPsec encryption, then verify. Includes DPI/censorship-bypass notes.
+arguments:
+  - name: device_a
+    description: First configured device (config key or label from list_mikrotik_devices), e.g. site-a.
+    required: false
+  - name: device_b
+    description: Second configured device, e.g. site-b.
+    required: false
+  - name: tunnel_id
+    description: EoIP tunnel ID (0–65535). MUST be identical on both peers and unique per EoIP tunnel. Omit to let you pick one.
+    required: false
+  - name: encrypt
+    description: Secure EoIP with IPsec (shared secret). Recommended — EoIP is cleartext. "yes" (default) or "no".
+    required: false
+---
+
+You are building an **EoIP (Ethernet-over-IP) tunnel between two MikroTik routers**
+this server can both reach. EoIP is unique among these tunnels: it is **Layer 2** —
+it transports Ethernet frames, so bridging the EoIP interface at both sites places
+them on **one broadcast domain** (same subnet spans both sites; ARP, DHCP, and
+broadcast cross the tunnel). That is powerful and dangerous: a broadcast storm or a
+loop now spans both sites. Use it only when you genuinely need shared L2; for routed
+L3 connectivity prefer GRE/IPIP/WireGuard. **EoIP is unencrypted** — secure with
+IPsec (default here). Drive **both** routers via the `device` argument. Confirm
+before any change.
+
+Device A: {{device_a}}
+Device B: {{device_b}}
+Tunnel ID: {{tunnel_id}}
+Encrypt with IPsec: {{encrypt}}
+
+## 0. Discover and confirm (FIRST)
+
+- `list_mikrotik_devices`; resolve {{device_a}}/{{device_b}} — never substitute a
+  similar name; ask which two if omitted.
+- Both ends need to reach the other's public IP (EoIP uses protocol 47, like GRE).
+  Behind NAT ⇒ prefer IPsec-encrypted EoIP (ESP/4500) and flag it.
+- **L2 safety check:** confirm the user really wants a single stretched subnet. If a
+  DHCP server runs at both sites, decide which one serves the stretched VLAN (two
+  servers on one L2 = conflict). Warn about loop/STP risk before bridging.
+
+## 1. Facts (read-only, per device)
+
+Per side (`device=<name>`): `get_system_identity`, `list_interfaces`,
+`list_bridges` (or `list_interfaces`), `list_ip_addresses`, `get_routing_table`,
+`get_ip_cloud`. Record public/WAN address, WAN MTU, the LAN bridge each site uses,
+and the subnet to stretch.
+
+## 2. Plan
+
+Pick `tunnel_id` = `{{tunnel_id}}` (identical both sides, unique per EoIP). Decide
+the target bridge on each side. Confirm interface names (`eoip-<peer>`), tunnel-id,
+and the stretched subnet/VLAN with the user. If encrypting, generate a strong shared
+secret for `ipsec_secret` on both sides.
+
+## 3. Create the EoIP interfaces (symmetric)
+
+- On **A** (`device={{device_a}}`): `create_eoip_tunnel` — `name`=`eoip-{{device_b}}`,
+  `remote_address`=**B's** public IP, `local_address`=A's public IP,
+  `tunnel_id`={{tunnel_id}} (MUST match), `keepalive`=`10s,3`, `clamp_tcp_mss`=true,
+  `ipsec_secret`=<secret> if encrypting, `mtu` per step 6.
+- On **B**: mirror — `remote_address`=A's IP, `local_address`=B's IP, **same
+  `tunnel_id`**, identical `ipsec_secret`. (A mismatched tunnel_id silently fails.)
+
+## 4. Bridge the tunnel (the L2 step)
+
+On each side add the EoIP interface as a **bridge port** on the LAN bridge that owns
+the stretched subnet (bridge/port tools). Now the two LANs are one L2 domain.
+
+- **Strongly recommend enabling STP/RSTP** on both bridges so an accidental parallel
+  path can't create a bridging loop across the WAN.
+- Do NOT put an IP on the EoIP interface itself — it's a bridge member, not a routed
+  link (that's the difference from GRE/IPIP).
+
+## 5. Firewall — safely, per device
+
+Per side under Safe Mode (`enable_safe_mode`→edits→verify→`commit_safe_mode`; per-device):
+
+- Unencrypted: `input` accept `protocol=gre` from far WAN (EoIP rides GRE; cleartext).
+- IPsec-encrypted: `input` accept `udp dst-port=500,4500` + `protocol=ipsec-esp`.
+- Bridged L2 traffic is `forward`-chain; if `use-ip-firewall` is on, allow it.
+
+## 6. MTU / MSS (critical for L2)
+
+EoIP has GRE-like overhead AND carries full Ethernet frames, so MTU mismatch bites
+hard. Set the EoIP `mtu`/`l2mtu` high enough (the WAN path must carry the encapsulated
+frame — often needs the WAN to support ~1500+; otherwise lower the guests' effective
+MTU), keep `clamp_tcp_mss=true`, and clamp MSS on `forward`. Test large frames
+explicitly.
+
+## 7. Verify
+
+- `get_eoip_tunnel` each side: running=yes; tunnel-ids match. If encrypted,
+  `get_ipsec_active_peers` shows an established SA (no SA + it works ⇒ CLEAR, stop).
+- L2 proof: a host at site A should ARP-resolve and `ping` a host at site B **in the
+  same subnet** with no router hop; DHCP from the designated server should reach both.
+- Large-frame test to confirm MTU.
+
+## Bypassing country / DPI restrictions (legitimate circumvention)
+
+Lawful privacy/accessibility only. EoIP (protocol 47) is easily filtered:
+
+1. **Encrypt** so it rides IPsec ESP/UDP 4500.
+2. If blocked, **carry the bridge over a TLS transport** — OpenVPN in **ethernet
+   (TAP) mode** on TCP/443 is L2-capable and looks like HTTPS (see
+   `setup-openvpn-tunnel-between-sites`, `mode=ethernet`); bridge that instead of
+   EoIP. SSTP is L3/PPP (not L2), so it can't replace EoIP for bridging.
+3. Advanced: obfuscation via `/container` (XRay/Reality, sing-box) — not native.
+   For evasion, prefer OpenVPN-TAP/443 over raw EoIP. Never present obfuscation as a
+   guarantee.
+
+---
+
+Report per side: EoIP interface, remote/local, tunnel-id, which bridge it joined,
+IPsec SA proof, STP status, MTU/MSS, verification results. State which device each
+change ran on. Never apply changes the user hasn't approved.

package/prompts/setup-gre-tunnel-between-sites.md

@@ -0,0 +1,163 @@
+---
+name: setup-gre-tunnel-between-sites
+title: Build a GRE tunnel between two MikroTik devices
+description: Configure BOTH routers of a GRE site-to-site tunnel from one conversation — endpoints, addressing, routing, MTU/MSS, and (strongly recommended) IPsec encryption — then verify end to end. Includes DPI/censorship-bypass transport options.
+arguments:
+  - name: device_a
+    description: First configured device (config key or label from list_mikrotik_devices), e.g. site-a.
+    required: false
+  - name: device_b
+    description: Second configured device, e.g. site-b.
+    required: false
+  - name: tunnel_subnet
+    description: Small transit subnet for the GRE link itself in CIDR, e.g. 10.255.255.0/30 (A=.1, B=.2). Omit to let you pick one that doesn't collide with either LAN.
+    required: false
+  - name: encrypt
+    description: Whether to secure GRE with IPsec (a shared secret). Strongly recommended — GRE alone is cleartext. "yes" (default) or "no".
+    required: false
+---
+
+You are building a **GRE (Generic Routing Encapsulation) site-to-site tunnel
+between two MikroTik routers** this server can both reach. GRE is a lightweight L3
+tunnel: it routes IP (and multicast / dynamic-routing protocols like OSPF, which
+plain IPsec can't carry) between two public endpoints. **GRE by itself is
+UNENCRYPTED** — anyone on the path sees the inner packets — so unless the transport
+is already trusted, secure it with IPsec (this flow does so by default). You will
+drive **both** routers in one conversation via the `device` argument. Confirm the
+plan before any change; never write without approval.
+
+Device A: {{device_a}}
+Device B: {{device_b}}
+Transit subnet: {{tunnel_subnet}}
+Encrypt with IPsec: {{encrypt}}
+
+## 0. Discover and confirm both endpoints (do this FIRST)
+
+- Call `list_mikrotik_devices` to enumerate the configured routers (key, label,
+  transport target, default).
+- Resolve `{{device_a}}` / `{{device_b}}` against that inventory. If either is
+  missing or ambiguous, STOP and show the list — never substitute a similar name.
+  If either was omitted, ask the user which two devices to connect.
+- GRE needs each side to reach the **other's public IP** by protocol 47. Both ends
+  must have a routable public address (or a DDNS name + a path that permits GRE).
+  If a side is behind NAT, GRE only works if the NAT device forwards protocol 47
+  (many don't) — in that case prefer IPsec-encrypted GRE on UDP 4500, or switch to
+  WireGuard (`setup-wireguard-tunnel-between-sites`). Flag this early.
+
+## 1. Gather the facts (read-only, per device)
+
+For each of {{device_a}} and {{device_b}} with `device=<name>`:
+`get_system_identity`, `list_interfaces`, `list_ip_addresses`, `get_routing_table`,
+`get_ip_cloud`. Record each side's public/WAN address (or DDNS), WAN MTU, and the
+**LAN subnet(s)** to route. Confirm the two LANs do **not overlap** (overlap breaks
+routing — NAT or renumber one side and flag it).
+
+## 2. Pick non-colliding addressing
+
+- Transit subnet `{{tunnel_subnet}}` or a /30 that collides with neither LAN
+  (e.g. `10.255.255.0/30`); A=`.1`, B=`.2`.
+- Decide encryption: if `{{encrypt}}` is empty or "yes", generate a strong shared
+  secret (long, random) to pass as `ipsec_secret` on **both** sides — RouterOS then
+  auto-creates the IPsec policy that encrypts the GRE. Confirm interface names
+  (`gre-<peer>`), transit IPs, and each side's advertised LAN back to the user.
+
+## 3. Create the GRE interfaces (symmetric endpoints)
+
+On **A** (`device={{device_a}}`): `create_gre_tunnel`
+
+- `name` = e.g. `gre-{{device_b}}`
+- `remote_address` = **B's** public IP/DDNS
+- `local_address` = A's own public IP (pin it if A has multiple WANs)
+- `keepalive` = `10s,3` (so the interface goes down fast if the far side dies)
+- `clamp_tcp_mss` = true (avoids PMTU black-holing — see step 6)
+- `ipsec_secret` = the shared secret (only when encrypting)
+- `mtu` = 1476 (GRE overhead is 24 bytes; lower further when also IPsec-wrapped —
+  see step 6)
+
+On **B** (`device={{device_b}}`): mirror — `remote_address` = **A's** public IP,
+`local_address` = B's public IP, same `keepalive`, `clamp_tcp_mss`, and the
+**identical** `ipsec_secret`.
+
+## 4. Address the tunnel
+
+`add_ip_address` the transit IP on each GRE interface (A: `10.255.255.1/30` on
+`gre-...`; B: `10.255.255.2/30`). This gives the tunnel a connected route.
+
+## 5. Route each far LAN over the tunnel
+
+- On A: `add_route` (`device={{device_a}}`) `dst-address=<B's LAN>`
+  `gateway=<A's gre interface>` (or `gateway=10.255.255.2`).
+- On B: mirror with A's LAN.
+- For dynamic routing instead of static routes, GRE can carry OSPF — add the GRE
+  interface to an OSPF area on both sides (see `setup-ospf-peering`); this is a key
+  reason to choose GRE over IPsec-only.
+
+## 6. Firewall — safely, per device
+
+Per side under Safe Mode (`enable_safe_mode` `device=<name>` → edits → verify →
+`commit_safe_mode`; per-device, independent commit):
+
+- If **unencrypted GRE**: `input` chain accept `protocol=gre` from the far side's
+  WAN. (Reminder to the user: this is cleartext.)
+- If **IPsec-encrypted GRE**: `input` chain accept `protocol=udp dst-port=500,4500`
+  (IKE + NAT-T) and `protocol=ipsec-esp` from the far WAN; the decrypted GRE is then
+  handled internally. Ensure any `action=fasttrack`/`accept` for established traffic
+  doesn't bypass the IPsec policy (put the IPsec accepts high).
+- `forward` chain: accept traffic between the two LANs both directions.
+- Do not masquerade the tunnel/transit subnet (breaks return routing).
+
+## 7. MTU / MSS (the silent-failure trap)
+
+Encapsulation shrinks the usable MTU; small pings pass but large TLS/file flows
+stall. GRE = 24 bytes overhead; GRE + IPsec (ESP) = ~70+ bytes. So:
+
+- Set the GRE interface MTU ~1476 (plain) or ~1400 (GRE-over-IPsec); lower on PPPoE.
+- Keep `clamp_tcp_mss=true` on the tunnel (set in step 3) and/or add a `forward`
+  mangle `change-mss new-mss=clamp-to-pmtu tcp-flags=syn` rule so TCP fits.
+
+## 8. Verify end to end
+
+- From A (`ping` `device={{device_a}}`): the transit IP (`10.255.255.2`), then a
+  host in B's LAN with `src_address` = A's LAN IP. Repeat from B.
+- `get_gre_tunnel` on each side: interface **running=yes** (keepalive up).
+- If encrypted: `get_ipsec_active_peers` on both — an established SA proves the GRE
+  is actually protected. If there's no SA but GRE still pings, the traffic is
+  flowing in the CLEAR — stop and fix the IPsec policy.
+- Large-payload test: ping size 1400 `do-not-fragment`; failure ⇒ revisit MTU/MSS.
+
+## Bypassing country / DPI restrictions (legitimate censorship circumvention)
+
+For lawful privacy / accessibility on networks you're authorized to use — comply
+with local law and service terms. GRE is easy for a network to block (protocol 47
+is uncommon and frequently filtered), so bypassing usually means **not sending raw
+GRE across the hostile path**:
+
+1. **Always encrypt and ride ESP/NAT-T.** Use `ipsec_secret` so the tunnel travels
+   as IPsec ESP over **UDP 4500** (NAT-T) rather than bare protocol 47 — 4500 is far
+   more likely to pass and the payload is hidden. This is the single biggest win.
+2. **IKEv2 over a common UDP port.** IPsec IKEv2 (`setup-ipsec-site-to-site`) on
+   500/4500 is widely permitted; move to it if 47 and 4500 alike are throttled.
+3. **Wrap the routed tunnel in a TLS-looking transport.** Where DPI blocks IKE/ESP
+   too, bring up an **SSTP** tunnel (PPP-over-TLS, **TCP 443** — looks like HTTPS)
+   or **OpenVPN TCP/443** between the sites and route the far LANs over that instead
+   of GRE, or run GRE _inside_ it. Trades throughput for reachability.
+4. **Port/endpoint agility.** Use DDNS (`/ip cloud`) so a dynamic endpoint stays
+   reachable, and prefer common ports (443) for whatever encrypted transport carries
+   the tunnel.
+5. **Advanced obfuscation via a RouterOS container.** The strongest anti-DPI tools
+   (XRay/VLESS+Reality, sing-box, Shadowsocks, obfs4) are **not native** to
+   RouterOS. Run one in a **`/container`** (or a VPS you control) and route the site
+   link through it. Heaviest option; confirm container support and spare resources
+   first.
+
+GRE's strength is carrying multicast/dynamic routing, not stealth — if the user's
+primary goal is _evading blocks_, recommend WireGuard or an SSTP/OpenVPN-TLS
+transport (options above) and use GRE only inside that protected path. Never present
+obfuscation as a guarantee — it is an arms race.
+
+---
+
+Report, per side: GRE interface name, remote/local addresses, transit IP, whether
+IPsec is active (and proof of the SA), routes and firewall rules added, MTU/MSS
+settings, and the verification results. State plainly which device each change ran
+on. Never apply changes the user hasn't approved.

package/prompts/setup-ipip-tunnel-between-sites.md

@@ -0,0 +1,110 @@
+---
+name: setup-ipip-tunnel-between-sites
+title: Build an IPIP tunnel between two MikroTik devices
+description: Configure BOTH routers of an IP-in-IP (IPIP) site-to-site tunnel from one conversation — endpoints, addressing, routing, MTU/MSS, and (recommended) IPsec encryption — then verify end to end. Includes DPI/censorship-bypass notes.
+arguments:
+  - name: device_a
+    description: First configured device (config key or label from list_mikrotik_devices), e.g. site-a.
+    required: false
+  - name: device_b
+    description: Second configured device, e.g. site-b.
+    required: false
+  - name: tunnel_subnet
+    description: Small transit subnet for the tunnel link in CIDR, e.g. 10.255.255.0/30 (A=.1, B=.2). Omit to let you pick one that doesn't collide with either LAN.
+    required: false
+  - name: encrypt
+    description: Secure IPIP with IPsec (shared secret). Recommended — IPIP is cleartext. "yes" (default) or "no".
+    required: false
+---
+
+You are building an **IPIP (IP-in-IP) site-to-site tunnel between two MikroTik
+routers** this server can both reach. IPIP is the **leanest L3 tunnel** — it
+encapsulates unicast IPv4 in IPv4 with only 20 bytes of overhead (less than GRE),
+but it carries **no multicast and no dynamic-routing protocols** (if you need OSPF
+or multicast over the tunnel, use GRE instead — `setup-gre-tunnel-between-sites`).
+Like GRE, **IPIP is unencrypted**, so secure it with IPsec unless the transport is
+already trusted (this flow does by default). Drive **both** routers in one
+conversation via the `device` argument. Confirm the plan before any change.
+
+Device A: {{device_a}}
+Device B: {{device_b}}
+Transit subnet: {{tunnel_subnet}}
+Encrypt with IPsec: {{encrypt}}
+
+## 0. Discover and confirm both endpoints (FIRST)
+
+- `list_mikrotik_devices`; resolve {{device_a}}/{{device_b}} against it — never
+  substitute a similar name. Ask which two if omitted.
+- Both ends need to reach the other's public IP by **protocol 4 (IPIP)**. If a side
+  is behind NAT that doesn't forward protocol 4, prefer IPsec-encrypted IPIP (rides
+  ESP/UDP 4500) or WireGuard. Flag it.
+
+## 1. Facts (read-only, per device)
+
+For each side (`device=<name>`): `get_system_identity`, `list_interfaces`,
+`list_ip_addresses`, `get_routing_table`, `get_ip_cloud`. Record public/WAN
+address, WAN MTU, and LAN subnet(s). Confirm the two LANs do **not overlap**.
+
+## 2. Addressing
+
+Transit `{{tunnel_subnet}}` or a /30 that collides with neither LAN (A=.1, B=.2).
+If encrypting, generate a strong shared secret to use as `ipsec_secret` on **both**
+sides. Confirm interface names (`ipip-<peer>`), transit IPs, advertised LANs.
+
+## 3. Create the IPIP interfaces (symmetric)
+
+- On **A** (`device={{device_a}}`): `create_ipip_tunnel` — `name`=`ipip-{{device_b}}`,
+  `remote_address`=**B's** public IP, `local_address`=A's public IP,
+  `keepalive`=`10s,3`, `clamp_tcp_mss`=true, `ipsec_secret`=<secret> (if encrypting),
+  `mtu`=1480 (20 B overhead; ~1400 when also IPsec-wrapped).
+- On **B**: mirror — `remote_address`=**A's** IP, `local_address`=B's IP, identical
+  `ipsec_secret`.
+
+## 4. Address, route
+
+- `add_ip_address` the transit IP on each ipip interface (A `10.255.255.1/30`, B `.2`).
+- `add_route` far LAN via the tunnel on each side (A: dst=B-LAN gw=ipip iface; B mirror).
+
+## 5. Firewall — safely, per device
+
+Per side under Safe Mode (`enable_safe_mode`→edits→verify→`commit_safe_mode`; per-device):
+
+- Unencrypted: `input` accept `protocol=ipip` from far WAN (cleartext — remind user).
+- IPsec-encrypted: `input` accept `udp dst-port=500,4500` + `protocol=ipsec-esp`
+  from far WAN, placed high.
+- `forward`: accept both LANs both directions. Do not masquerade the transit subnet.
+
+## 6. MTU / MSS
+
+IPIP = 20 B overhead (+ ~50 with IPsec). Set iface MTU ~1480 (~1400 encrypted),
+keep `clamp_tcp_mss=true`, and/or a `forward` mangle `change-mss
+new-mss=clamp-to-pmtu tcp-flags=syn`. Lower on PPPoE.
+
+## 7. Verify
+
+- `ping` (`device=A`) the transit IP, then a B-LAN host with `src_address`=A-LAN IP;
+  repeat from B.
+- `get_ipip_tunnel` each side: running=yes. If encrypted, `get_ipsec_active_peers`
+  must show an established SA — no SA + tunnel pings ⇒ traffic is in the CLEAR, stop.
+- Large payload: ping size 1400 do-not-fragment ⇒ MTU sanity.
+
+## Bypassing country / DPI restrictions (legitimate circumvention)
+
+Lawful privacy/accessibility only; comply with local law. Raw IPIP (protocol 4) is
+easily filtered, so:
+
+1. **Encrypt** so it rides IPsec ESP/UDP 4500 (much more likely to pass, payload
+   hidden) — the biggest win.
+2. If IKE/ESP is also blocked, **wrap in a TLS transport** (SSTP or OpenVPN TCP/443,
+   see `setup-sstp-tunnel-between-sites` / `setup-openvpn-tunnel-between-sites`) and
+   route the far LANs over that.
+3. Advanced: obfuscation (XRay/Reality, sing-box, Shadowsocks, obfs4) in a
+   **`/container`** or VPS — not native to RouterOS. Heaviest option.
+   IPIP's value is minimal overhead, not stealth — for evasion prefer a TLS transport
+   and keep IPIP only inside the protected path. Never present obfuscation as a guarantee.
+
+---
+
+Report per side: interface name, remote/local, transit IP, IPsec SA proof, routes +
+firewall added, MTU/MSS, verification results. State which device each change ran on.
+Never apply changes the user hasn't approved.