@usex/mikrotik-mcp 4.6.0 → 4.8.0

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

@@ -0,0 +1,136 @@
+---
+name: setup-openvpn-tunnel-between-sites
+title: Build an OpenVPN (TLS) tunnel between two MikroTik devices
+description: Configure a MikroTik-to-MikroTik OpenVPN site-to-site link — certificates, PPP profile + secret, server + client, L3 (ip) or L2 (ethernet) mode, routing, firewall — over TCP/UDP 443 for HTTPS-like camouflage. Verified end to end, with DPI/censorship-bypass guidance.
+arguments:
+  - name: server_device
+    description: The device that will run the OpenVPN SERVER — reachable public IP/DDNS + a certificate. Config key or label from list_mikrotik_devices.
+    required: false
+  - name: client_device
+    description: The device that will run the OpenVPN CLIENT (may be behind NAT). Config key or label.
+    required: false
+  - name: mode
+    description: Tunnel mode — "ip" (L3 routed, default) or "ethernet" (L2 TAP, bridgeable across sites). Omit for ip.
+    required: false
+  - name: protocol
+    description: Transport — "tcp" (works with 443 camouflage, survives more DPI) or "udp" (faster). Omit for tcp when bypassing blocks, udp otherwise.
+    required: false
+  - name: port
+    description: Port for OpenVPN. 1194 is default; use 443 to look like HTTPS through restrictive networks. Omit for 1194.
+    required: false
+---
+
+You are building an **OpenVPN site-to-site tunnel between two MikroTik routers**.
+OpenVPN is a mature TLS VPN: it can be **L3 routed (`mode=ip`)** or **L2 bridgeable
+(`mode=ethernet`/TAP)**, over **TCP or UDP**, and on **any port** — running it on
+**TCP 443** makes it look like HTTPS, a strong DPI-bypass option (a different TLS
+fingerprint than SSTP). It is client↔server: one device is the **server** (reachable
+endpoint + certificate), the other the **client** (NAT-friendly). Drive both via the
+`device` argument. Confirm before writing — this touches certificates, PPP, and the
+firewall.
+
+Server device: {{server_device}}
+Client device: {{client_device}}
+Mode: {{mode}}
+Protocol: {{protocol}}
+Port: {{port}}
+
+## 0. Discover and assign roles (FIRST)
+
+- `list_mikrotik_devices`; resolve {{server_device}}/{{client_device}} — never
+  substitute a similar name; ask which is which if omitted.
+- The **server** must be reachable on the chosen `port`/`protocol` (static WAN or
+  DDNS). The **client** only needs outbound reach. Confirm roles.
+- Choose `mode`: **ip** for routed site-to-site (recommended default — cleaner,
+  faster); **ethernet** only if the user needs a stretched L2 domain (then bridge the
+  interface at both ends, with the same STP / single-DHCP warnings as EoIP/VXLAN).
+
+## 1. Facts (read-only, per device)
+
+Per side: `get_system_identity`, `list_ip_addresses`, `get_routing_table`,
+`get_ip_cloud`, and on the server `list_certificates`. Record server public
+address/DDNS, LAN subnets (must not overlap for `mode=ip`), and existing certs.
+
+## 2. Certificates
+
+OpenVPN needs a server certificate; with `require_client_certificate=true` it also
+needs a client cert (recommended — stronger than username/password alone):
+
+- If absent: `create_certificate` a CA → `sign_certificate` (self-signed); then a
+  **server** cert (CN=server address) and a **client** cert, each `sign_certificate`
+  by the CA.
+- `import_certificate` the CA (and client cert) onto the client. RouterOS OpenVPN
+  historically wants explicit certs on both ends — plan for it rather than relying on
+  username/password only.
+
+## 3. PPP profile + secret (server side)
+
+- `create_ppp_profile` — `local-address`=server tunnel IP, `remote-address`=client
+  tunnel IP or pool; optional DNS/routes.
+- `create_ppp_secret` — strong `name`/`password`, `service=ovpn`, `profile`=above.
+
+## 4. Enable the OpenVPN server (server side)
+
+`add_ovpn_server` (`device={{server_device}}`) — `name`=`ovpn-srv`, `port`={{port}}
+or (443 for camouflage / 1194 default), `protocol`={{protocol}} or tcp,
+`mode`={{mode}} or ip, `certificate`=<server cert>, `require_client_certificate=true`,
+`auth=sha256`, `cipher=aes256-gcm,aes256-cbc`, `tls_version=only-1.2`,
+`default_profile`=the profile, `enabled` (or `enable_ovpn_server`). Strong cipher +
+TLS 1.2 both hardens and looks like modern HTTPS.
+
+## 5. Client (client side)
+
+`create_ovpn_client` (`device={{client_device}}`) — `name`=`ovpn-{{server_device}}`,
+`connect_to`=server public IP/DDNS, `port`={{port}} or match, `protocol`=match,
+`mode`=match, `user`/`password`=the PPP secret, `certificate`=<client cert>,
+`verify_server_certificate=true`, `cipher`/`auth`/`tls_version` matching the server.
+Use `route_nopull=true` if you want to control routing manually (recommended for
+site-to-site), else the server can push routes.
+
+## 6. Route (mode=ip) or bridge (mode=ethernet)
+
+- **mode=ip:** transit link is up once connected; `add_route` far LAN on each side
+  (server→client-LAN, client→server-LAN) via the tunnel interface / transit IP. Or
+  push routes from the server profile.
+- **mode=ethernet:** add the OVPN interface as a **bridge port** on each side's LAN
+  bridge (one L2 domain) — enable STP, single DHCP authority, watch MTU.
+
+## 7. Firewall — safely
+
+Under Safe Mode per device: server `input` accept `protocol={{protocol}} (tcp)
+dst-port={{port}}` (443/1194) from the client's source (any if dynamic), high in the
+chain; both sides `forward` allow the two LANs.
+
+## 8. MTU / MSS
+
+OpenVPN adds notable overhead; TCP mode risks TCP-in-TCP stalls. Set the client
+`max_mtu` conservatively (~1400), clamp MSS on `forward`. UDP mode is faster where
+it isn't blocked; TCP/443 is for reachability.
+
+## 9. Verify
+
+- Server: `list_ovpn_servers`/`get_ovpn_server` running; the client appears as a
+  connected session. Client: `get_ovpn_client` status `connected`, address assigned.
+- `ping` (`device=server`) client tunnel/LAN (with `src_address`=server-LAN), repeat
+  from client. For `mode=ethernet`, prove same-subnet L2 reachability + DHCP. Large-
+  payload ping to confirm MTU.
+
+## Bypassing country / DPI restrictions (legitimate circumvention)
+
+Lawful privacy/accessibility only; comply with local law and terms. OpenVPN on
+**TCP 443** presents a TLS session on the HTTPS port — a strong native bypass with a
+**different fingerprint from SSTP**, so it's the natural second option if SSTP is
+blocked. Maximize blend-in: `protocol=tcp`, `port=443`, `tls_version=only-1.2`, AES-
+GCM, valid-looking cert. Note: classic OpenVPN has a recognizable TLS handshake that
+sophisticated DPI (active probing / TLS-fingerprint allow-lists) can still flag —
+if that's the adversary, escalate to **container-based obfuscation** (XRay/VLESS+
+Reality, sing-box, Shadowsocks, obfs4) in a RouterOS `/container` or a VPS (not
+native, heaviest, most robust), or run WireGuard _inside_ this OpenVPN link. Compare
+with `setup-sstp-tunnel-between-sites` and pick the transport the local DPI doesn't
+recognize. Never present obfuscation as a guarantee — it's an arms race.
+
+---
+
+Report: certs used, PPP profile/secret, server + client settings (mode/protocol/port),
+routing or bridging, firewall added, MTU/MSS, verification results. State which device
+each change ran on. Never apply changes the user hasn't approved.

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

@@ -0,0 +1,136 @@
+---
+name: setup-sstp-tunnel-between-sites
+title: Build an SSTP (TLS/443) tunnel between two MikroTik devices
+description: Configure a MikroTik-to-MikroTik SSTP site-to-site link — server certificate, PPP profile + secret, client, routing, firewall — over TCP 443 so it looks like HTTPS. The go-to transport for bypassing VPN blocks / DPI. Verified end to end.
+arguments:
+  - name: server_device
+    description: The device that will run the SSTP SERVER — the one with a reachable public IP / DDNS and (ideally) a certificate. Config key or label from list_mikrotik_devices.
+    required: false
+  - name: client_device
+    description: The device that will run the SSTP CLIENT (may be behind NAT). Config key or label.
+    required: false
+  - name: tunnel_subnet
+    description: Transit subnet for the PPP link, e.g. 10.255.255.0/30 (server=.1 local, client=.2 remote). Omit to let you pick one that collides with neither LAN.
+    required: false
+  - name: port
+    description: TCP port for SSTP. Default and recommended 443 (looks like HTTPS, survives most DPI). Omit for 443.
+    required: false
+---
+
+You are building an **SSTP site-to-site tunnel between two MikroTik routers**. SSTP
+is **PPP inside TLS over TCP (default 443)** — on the wire it is nearly
+indistinguishable from an HTTPS session, which makes it the **best native RouterOS
+choice for bypassing VPN blocks and DPI**. It is client↔server (asymmetric): one
+device is the **server** (needs a reachable endpoint + a TLS certificate), the other
+is the **client** (can be behind NAT). Drive both via the `device` argument. This
+touches certificates, PPP, and the firewall — go carefully and confirm before writing.
+
+Server device: {{server_device}}
+Client device: {{client_device}}
+Transit subnet: {{tunnel_subnet}}
+Port: {{port}}
+
+## 0. Discover and assign roles (FIRST)
+
+- `list_mikrotik_devices`; resolve {{server_device}}/{{client_device}} — never
+  substitute a similar name; ask which is which if omitted.
+- The **server** must be reachable on the chosen TCP `port` (static WAN or DDNS via
+  `/ip cloud`). The **client** only needs outbound TCP to that port — NAT-friendly.
+  Confirm roles with the user before proceeding.
+
+## 1. Facts (read-only, per device)
+
+Per side (`device=<name>`): `get_system_identity`, `list_ip_addresses`,
+`get_routing_table`, `get_ip_cloud`, and on the server `list_certificates`. Record
+the server's public address/DDNS, each LAN subnet (must not overlap), and whether a
+usable server certificate already exists.
+
+## 2. Server certificate (server side)
+
+SSTP requires a TLS certificate on the server. If none exists:
+
+- `create_certificate` a local CA, then `create_certificate` a server cert (common-
+  name = the server's public IP/DDNS the client will connect to), `sign_certificate`
+  both (CA self-signed, server signed by the CA). Note the server cert name.
+- The client should trust that CA: either `import_certificate` the CA on the client,
+  or set the client's `verify_server_certificate=false` (simpler, but skips
+  authenticity — acceptable only if the PSK-like PPP credentials are strong; state
+  the trade-off). A publicly-trusted (Let's Encrypt) cert avoids this — see
+  `manage-certificates`.
+
+## 3. PPP profile + secret (server side)
+
+- `create_ppp_profile` — set `local-address`=server transit IP (e.g. `10.255.255.1`),
+  `remote-address`=client transit IP (e.g. `10.255.255.2`) or a small pool. Optionally
+  set DNS. This profile defines the tunnel's L3 endpoints.
+- `create_ppp_secret` — `name`/`password` (strong), `service=sstp`, `profile`=the
+  profile above. These are the client's login credentials.
+
+## 4. Enable the SSTP server (server side)
+
+`set_sstp_server` (`device={{server_device}}`) — `enabled=true`,
+`certificate`=<server cert>, `port`={{port}} or 443, `default_profile`=the profile,
+`authentication=mschap2` (drop weaker methods), `tls_version=only-1.2`, `pfs=true`,
+`force_aes=true`. Strong ciphers + TLS 1.2-only both hardens and makes the flow look
+like modern HTTPS.
+
+## 5. Client (client side)
+
+`create_sstp_client` (`device={{client_device}}`) — `name`=`sstp-{{server_device}}`,
+`connect_to`/server address = the server's public IP/DDNS, `port`={{port}} or 443,
+`user`/`password` = the PPP secret from step 3, `verify_server_certificate` per step 2,
+`tls_version=only-1.2`, `pfs=true`, `authentication=mschap2`. The client auto-creates
+the PPP interface and gets the transit `remote-address`.
+
+## 6. Route each far LAN
+
+The transit /30 is connected once the PPP link is up. Add routes for the far LANs:
+
+- On the server: `add_route` dst=client-LAN gw=the client's transit IP (or the
+  dynamic SSTP interface).
+- On the client: `add_route` dst=server-LAN gw=the server's transit IP (or the SSTP
+  interface). Or push routes via the PPP profile.
+
+## 7. Firewall — safely
+
+Under Safe Mode per device (`enable_safe_mode`→edits→verify→`commit_safe_mode`):
+
+- Server `input`: accept `protocol=tcp dst-port={{port}}` (443) from anywhere the
+  client may source from (dynamic clients ⇒ from any), placed above any default drop.
+- Both sides `forward`: allow the two LANs both directions.
+
+## 8. MTU / MSS
+
+SSTP over TCP/TLS adds overhead and is prone to TCP-in-TCP meltdown on lossy links.
+Set the client `max_mtu`/`max_mru` conservatively (~1400) and clamp MSS on `forward`.
+Prefer this transport for _reachability_, not raw throughput.
+
+## 9. Verify
+
+- Server: `get_sstp_server` enabled; check active PPP (the client should appear as a
+  connected session). Client: `get_sstp_client` — status `connected`, transit IP
+  assigned.
+- `ping` (`device=server`) the client transit IP then a client-LAN host with
+  `src_address`=server-LAN IP; repeat from the client. `traceroute` if a path is off.
+
+## Why this is the bypass workhorse (legitimate circumvention)
+
+Lawful privacy/accessibility only; comply with local law and terms. SSTP on TCP 443
+**is** the DPI-bypass technique for native RouterOS — it presents as a standard TLS
+session to a common HTTPS port, so it passes most "block VPN protocols" filters that
+stop WireGuard/IKE/GRE. To maximize blend-in: keep `port=443`, `tls_version=only-1.2`,
+strong AES + PFS, and a certificate with a plausible CN. If SSTP itself is
+fingerprinted/blocked (active probing, TLS-fingerprint allow-lists), escalate to:
+**OpenVPN TCP/443** (`setup-openvpn-tunnel-between-sites`) for a different TLS
+signature, or **container-based obfuscation** (XRay/VLESS+Reality, sing-box,
+Shadowsocks, obfs4) run in a RouterOS `/container` or a VPS — not native, heaviest,
+most robust. You can also run WireGuard _inside_ this SSTP link so the WG handshake
+never touches the open internet. Never present obfuscation as a guarantee — it's an
+arms race.
+
+---
+
+Report: server cert used, PPP profile/secret, server settings, client status, routes
+
+- firewall added, MTU/MSS, verification results. State which device each change ran
+  on. Never apply changes the user hasn't approved.

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

@@ -4,19 +4,29 @@ title: Build a tunnel between two MikroTik devices
 description: Configure BOTH routers of a site-to-site tunnel from one conversation, then verify it end to end.
 arguments:
   - name: device_a
-    description: Name of the first configured device (see list_mikrotik_devices), e.g. site-a.
-    required: true
+    description: First configured device (config key or label from list_mikrotik_devices), e.g. site-a. Omit to discover and choose.
+    required: false
   - name: device_b
-    description: Name of the second configured device, e.g. site-b.
-    required: true
+    description: Second configured device, e.g. site-b. Omit to discover and choose.
+    required: false
   - name: technology
-    description: Tunnel type to use — wireguard, ipsec, gre, eoip, or "recommend" to let you choose.
+    description: Tunnel type — wireguard, ipsec, gre, ipip, eoip, vxlan, sstp, ovpn, or "recommend" to let you choose. For a deep, tech-specific walkthrough use setup-wireguard-tunnel-between-sites or setup-gre-tunnel-between-sites.
     required: false
 ---
 
 You are configuring a **site-to-site tunnel between two MikroTik routers** that
 this server can both reach. You will drive BOTH devices in one flow by passing
-the `device` argument on each tool call.
+the `device` argument on each tool call. This is the general chooser-and-builder;
+for a detailed, tech-specific flow prefer the dedicated per-technology prompts,
+which cover keys/certs, MTU/MSS, and DPI-bypass transports in depth:
+**`setup-wireguard-tunnel-between-sites`** (WireGuard),
+**`setup-gre-tunnel-between-sites`** (GRE + IPsec),
+**`setup-ipip-tunnel-between-sites`** (IP-in-IP),
+**`setup-eoip-tunnel-between-sites`** (L2 bridgeable),
+**`setup-vxlan-tunnel-between-sites`** (L2 overlay / multipoint),
+**`setup-ipsec-site-to-site`** (IKEv2 policy-based),
+**`setup-sstp-tunnel-between-sites`** and
+**`setup-openvpn-tunnel-between-sites`** (TLS/443 — the bypass workhorses).
 
 Device A: {{device_a}}
 Device B: {{device_b}}
@@ -24,6 +34,13 @@ Requested technology: {{technology}}
 
 Work in this order, confirming the plan before any change:
 
+0. **Discover both endpoints.** Call `list_mikrotik_devices` first and resolve
+   {{device_a}} / {{device_b}} against it — never substitute a similar name (these
+   are different physical routers). If either was omitted, ask which two devices to
+   connect. Note which side (if any) has a reachable public endpoint vs. is behind
+   NAT — if **both** are behind NAT with no forward, a direct tunnel can't form
+   (use a reachable side or a relay/VPS).
+
 1. **Inventory both ends.** Call `list_mikrotik_devices` first. Then, for each of
    {{device_a}} and {{device_b}}, gather facts with `device=<name>`:
    `get_system_identity`, `list_interfaces`, `list_ip_addresses`,
@@ -48,10 +65,40 @@ Work in this order, confirming the plan before any change:
    (`device=<name>`) per device before firewall edits, verify, then
    `commit_safe_mode` — Safe Mode is tracked per device, so each router commits
    independently.
-5. **Verify end to end.** From {{device_a}} run `ping` (`device={{device_a}}`) to
+5. **MTU / MSS.** Every tunnel shrinks the usable MTU (WireGuard ~60 B, GRE 24 B,
+   GRE+IPsec ~70+ B), so small pings pass but large TLS/file flows stall. Set the
+   tunnel interface MTU accordingly (WG 1420, GRE 1476, lower on PPPoE / when also
+   IPsec-wrapped) and clamp TCP MSS (`clamp-tcp-mss` on the tunnel, or a `forward`
+   mangle `change-mss new-mss=clamp-to-pmtu tcp-flags=syn`). Confirm non-overlapping
+   LANs before routing — overlap makes the far route ambiguous.
+6. **Verify end to end.** From {{device_a}} run `ping` (`device={{device_a}}`) to
    the far tunnel address and a host in B's LAN (set `src_address` to A's LAN IP);
    repeat from {{device_b}}. For IPsec, check `get_ipsec_active_peers` on both.
-   Use `traceroute` if a path is wrong.
+   Test a large payload (ping size 1400, do-not-fragment) to catch MTU issues. Use
+   `traceroute` if a path is wrong.
+
+## 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. Escalate only as far as the block requires:
+
+- **Port camouflage** — run the encrypted tunnel on a rarely-filtered port (UDP/443
+  for WireGuard, UDP 4500 for IPsec NAT-T). Cheapest; hides the port, not the
+  handshake.
+- **TLS-looking transport** — where DPI fingerprints WireGuard/IKE, wrap the routed
+  tunnel in **SSTP** (PPP-over-TLS, TCP 443 — looks like HTTPS) or **OpenVPN TCP/443**
+  (`create_sstp_client` / `create_ovpn_client`) and route the far LANs over that, or
+  run WG/GRE inside it. Trades throughput for reachability.
+- **Alternate fingerprint** — if one protocol is specifically blocked, switch: WG↔
+  IKEv2↔SSTP present different signatures on the wire.
+- **Container-based obfuscation (advanced)** — the strongest anti-DPI tools
+  (XRay/VLESS+Reality, sing-box, Shadowsocks, obfs4) are **not native** to RouterOS;
+  run one in a **`/container`** or on a VPS you control and route the site tunnel
+  through it. Confirm container support and spare resources first.
+
+Recommend the lightest option that works; never present obfuscation as a guarantee.
+The dedicated `setup-wireguard-tunnel-between-sites` and
+`setup-gre-tunnel-between-sites` prompts cover these transports in more depth.
 
 Report the tunnel parameters used on each side, the verification results, and any
 follow-ups (e.g. routes still needed). Never apply changes the user hasn't approved.

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

@@ -0,0 +1,129 @@
+---
+name: setup-vxlan-tunnel-between-sites
+title: Build a VXLAN overlay between two (or more) MikroTik devices
+description: Configure a VXLAN L2 overlay across MikroTik routers — VNI, VTEP peering, bridging, MTU — for multi-site / multi-tenant L2. Honest about RouterOS VTEP tooling limits; recommends EoIP for a simple two-site link.
+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: vni
+    description: VXLAN Network Identifier (VNI, 1–16777215). MUST match on every VTEP in this overlay. Omit to let you pick one.
+    required: false
+  - name: port
+    description: VXLAN UDP port. Default 8472 (Linux/MikroTik); 4789 is the IANA standard. Pick one that suits the path.
+    required: false
+---
+
+You are building a **VXLAN Layer-2 overlay across MikroTik routers** this server can
+reach. VXLAN encapsulates Ethernet in **UDP** and identifies each virtual segment by
+a 24-bit **VNI**, so it scales to millions of segments and — unlike EoIP — is
+naturally **multipoint** (three+ sites on one overlay) and firewall-friendly (it's
+just UDP). Two honest caveats up front, state them to the user:
+
+1. **For a simple TWO-site L2 link, EoIP is usually the better fit** (fewer moving
+   parts, built-in keepalive + IPsec option). Use VXLAN when you need **multipoint**
+   or many segments. If the user only wants two sites bridged, recommend
+   `setup-eoip-tunnel-between-sites` unless they specifically want VXLAN.
+2. **RouterOS unicast VXLAN needs per-peer VTEP entries** (`/interface vxlan vteps`).
+   This MCP's `create_vxlan_tunnel` builds the VXLAN interface and its options but
+   does **not** expose a dedicated add-VTEP tool. So for static-unicast peering you
+   will add the remote VTEPs with the raw command tool (`run_routeros_command` /
+   the raw-command escape hatch) — call this out and get approval, or use a
+   **multicast** group for flood/learn if the WAN path carries multicast (rare across
+   the internet).
+
+Drive each device via the `device` argument. Confirm the plan before any change.
+
+Device A: {{device_a}}
+Device B: {{device_b}}
+VNI: {{vni}}
+UDP port: {{port}}
+
+## 0. Discover and confirm (FIRST)
+
+- `list_mikrotik_devices`; resolve the endpoints — never substitute a similar name;
+  ask which devices if omitted. VXLAN can span more than two, so ask for the full
+  VTEP list if it's a multipoint overlay.
+- Because VXLAN is UDP, each VTEP just needs to reach the others' public IP on the
+  chosen `port` — NAT-friendly (unlike GRE/EoIP protocol 47). Note each site's
+  reachable source IP (the local VTEP address).
+- **L2 safety:** as with EoIP, VXLAN stretches a broadcast domain — decide the single
+  DHCP authority, enable STP, and warn about loops before bridging.
+
+## 1. Facts (read-only, per device)
+
+Per side (`device=<name>`): `get_system_identity`, `list_interfaces`,
+`list_ip_addresses`, `get_routing_table`, `get_ip_cloud`. Record each VTEP's source
+IP/interface, WAN MTU, target bridge, and the segment to carry.
+
+## 2. Plan
+
+Pick `vni`={{vni}} (identical on every VTEP), `port`={{port}} or 8472, and the local
+source address/interface for each VTEP. Confirm interface names (`vxlan<vni>`) and
+the peer VTEP IP list with the user.
+
+## 3. Create the VXLAN interface (each device)
+
+On each device: `create_vxlan_tunnel` — `name`=`vxlan{{vni}}`, `vni`={{vni}},
+`port`={{port}}, `local_address`=this site's VTEP source IP (or `interface`=source
+interface), `mtu` per step 6. (`vteps_ip_version` if you're doing IPv6 VTEPs.)
+
+## 4. Peer the VTEPs (the multipoint step)
+
+For **static unicast** (internet-friendly): on each device add every OTHER site's
+VTEP as a remote VTEP under this VXLAN interface. Since there's no dedicated tool,
+use the raw-command tool with the user's approval, e.g.
+`/interface vxlan vteps add interface=vxlan{{vni}} remote-ip=<peer VTEP IP>` — repeat
+for each peer, on each device (full mesh). For **multicast** flood/learn instead,
+set the multicast group on the interface (only viable if the path carries multicast).
+
+## 5. Bridge the overlay (L2 step)
+
+Add the VXLAN interface as a **bridge port** on the LAN bridge that owns the segment,
+on every site. Enable **STP/RSTP**. Do not put an IP on the VXLAN interface (it's a
+bridge member). One DHCP authority for the stretched segment.
+
+## 6. MTU / MSS (VXLAN eats 50 bytes)
+
+VXLAN adds a **50-byte** header (UDP+VXLAN+inner-Ethernet). If the WAN MTU is 1500,
+either raise the underlay MTU/L2MTU to ~1550 (if the path supports jumbo) or lower
+the guests' effective MTU / clamp MSS so encapsulated frames don't fragment. This is
+the #1 VXLAN gotcha — verify with a large-frame test.
+
+## 7. Firewall — safely, per device
+
+Per side under Safe Mode: `input` accept `protocol=udp dst-port={{port}}` (or 8472)
+from each peer VTEP IP. Bridged traffic is `forward` (allow if `use-ip-firewall`).
+VXLAN has **no built-in encryption** — if the underlay is untrusted, run VXLAN over
+an IPsec transport policy (protect UDP/{{port}} between the VTEPs) or inside another
+encrypted tunnel; call this out.
+
+## 8. Verify
+
+- `get_vxlan_tunnel` each device: interface up, VNI/port correct, VTEP peers present.
+- L2 proof: a host at one site ARP-resolves and `ping`s a host at another **in the
+  same subnet**, no router hop; DHCP from the designated server reaches all sites.
+- Large-frame test to confirm MTU (step 6).
+
+## Bypassing country / DPI restrictions (legitimate circumvention)
+
+Lawful privacy/accessibility only. VXLAN is plain UDP on a fixed port, so:
+
+1. **Move `port` to a common UDP port** (e.g. 443) so it blends with QUIC-like
+   traffic; update every VTEP to match.
+2. **Encrypt the underlay** (IPsec transport for UDP/{{port}}), both to protect and
+   to ride ESP/4500 where raw UDP is inspected.
+3. If VXLAN itself is blocked, **carry the bridge over OpenVPN-TAP/443** (L2, HTTPS-
+   like — see `setup-openvpn-tunnel-between-sites`).
+4. Advanced obfuscation (XRay/Reality, sing-box, obfs4) via `/container` — not native.
+   Never present obfuscation as a guarantee.
+
+---
+
+Report per device: VXLAN interface, VNI, port, local VTEP IP, peer VTEP list, bridge
+joined, STP status, MTU/MSS, and verification results — noting any raw-command steps
+used for VTEP peering. State which device each change ran on. Never apply changes the
+user hasn't approved.