Description
## Background
Citymesh manages MikroTik routers at cloud-seven, rupelmonde, and mobile-kit. Their routers already have WireGuard peers to the HydraGuard hub, giving the router itself access to the 10.10.0.0/16 mesh subnet. However, this routing is not currently propagated to LAN clients — so iPads, Mac Minis, and other devices on those local networks cannot reach remote render bodies at other venues.
## The Ask
Request Citymesh to configure their MikroTik routers to route 10.10.0.0/16 to LAN clients. Concretely, the router needs a policy route or NAT rule that forwards packets destined for 10.10.0.0/16 through its existing WireGuard interface, and a LAN-facing route advertisement (or static route on each device) so that LAN clients know to send that subnet to the gateway.
With this in place, any device on the local network (iPad, Android tablet, Mac Mini, etc.) automatically has access to the full WireGuard mesh without needing its own peer configuration.
## Why This Matters Now
This is the plan B for cross-venue iPad streaming (hydraheadipad). The primary plan is an in-app WireGuard tunnel via NEPacketTunnelProvider, which requires Xcode setup and per-device provisioning. Router-level routing is simpler to deploy and benefits all current and future devices on those networks — not just iOS.
## Venues Affected
- **mobile-kit** — highest priority; this is the primary iPad deployment target
- **cloud-seven** — MikroTik RB5009, Citymesh-managed
- **rupelmonde** — MikroTik RB5009, Citymesh-managed
## Action Items
1. Reach out to Citymesh with the specific routing request for each venue router.
2. Confirm the WireGuard interface name and allowed IPs on their side include 10.10.0.0/16.
3. Verify that a device on the LAN (e.g. an iPad) can ping a remote body IP (e.g. 10.10.x.x) after the change.
4. Document the resulting LAN route config in the hydraneck runbook.
## Notes
- The in-app tunnel approach (issue on hydraheadipad tracker) continues in parallel — this is an independent unblocking step.
- Once router-level routing is confirmed working, future devices (Android tablets, kiosk accessories) benefit automatically with zero per-device config.
[19/5, 14:08] Yentel Hollebeke: Dat moet hij gewoon naar zijn router sturen, maar daar moet dan nog een fw rule op komen
[19/5, 14:09] Yentel Hollebeke: Thing is dat die client in een 10.110 subnet zit van ons, en dat je hub dat niet terug gaat kunnen sturen dus ik ga moeten natten vrees ik achter het wireguard ip langs mijn kant
[19/5, 14:09] Yentel Hollebeke: Ik geef het straks een poging maar kan niets garanderen
[19/5, 14:28] Yentel Hollebeke: Mobilekit routing 10.10.0.0/16 naar wireguard muv 10.10.8.0/23 die voor ons datacenter noodzakelijk is (more specific route dus wordt op die manier by design naar ons gestuurd ipv over wireguard)
Ik check nu firewall rule dat clients op de mobilekit toelaat om over wireguard te gaan
[19/5, 14:36] Yentel Hollebeke: Kun je nog eens testen als je vanaf een client op de wifi van de mobilekit aan de 10.10.100.14 kan?
[19/5, 14:37] Yentel Hollebeke: Ik
- Route statisch 10.10.0.0/16. naar de WG interface
- Allow de Mobilekit LAN range 10.110.0.0/20 naar de WG richting 10.10.0.0/16
- NAT alles van 10.110.0.0/20 mobilekit LAN richting WG achter het WG ip adres zodat jullie server weet naar waar hij het moet terugsturen.
Kun je nog eens testen?