# OpenIoTHub reaches LAN services through a peer to peer tunnel > OpenIoTHub is a Dart client that opens a peer to peer path from your phone to services sitting behind a NAT, using a gateway you run on the local network and, if you want it, a server you host yourself. **OpenIoTHub/OpenIoTHub** — 💖Client for remote access to your network services (behind a NAT or firewall) with p2p transport. [通过内网穿透访问远程局域网服务和设备的客户端] - Repository: https://github.com/OpenIoTHub/OpenIoTHub - Stars: 525 · Forks: 74 - Language: Dart - License: MIT - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/openiothub-openiothub ## A tunnel aimed at one specific problem: reaching home from elsewhere OpenIoTHub solves a narrow problem well. It lets a client on a phone or laptop reach a service that sits inside a home or small office network, the kind of network where the router sits behind a carrier NAT and forwarding a fixed port is not practical. The project calls itself a client for remote access to network services behind a NAT or firewall using p2p transport, and it also frames the wider goal as giving you a private cloud and IoT platform for your own devices. That framing matters for who this suits. The intended user is someone who owns the network: a home lab, a small office, a rack in a spare room. There is no account signup step, no tenant model and no billing layer in the picture. The trade is that the responsibility for reachability moves onto you, because the pieces that make the tunnel work are programs you download and run yourself. The repository topic tags list iothub, tunnel, nat, proxy, socks5, ssh, rdp, vnc and aria2, which describes the shape of the problem space better than any feature list would. ## Three moving parts: the app, the gateway on your LAN, and an optional server The architecture is split across separate repositories, and understanding the split explains most of the setup friction. The client application is the OpenIoTHub app itself, written in Dart and packaged with Flutter build files across the android, ios, linux, macos and windows directories at the top of the repository. A separate program, the OpenIoTHub Gateway, is described as continuously running on the LAN to receive access requests, and it lives in its own gateway-go repository. Above those two sits a third component, the OpenIoTHub Server, published separately as server-go and marked as high level and not necessary for the common user. A self hosted server for OpenIoTHub is configured with its own port and secret key, and the gateway can then use that self built server by using the information and public network address you have configured. Data therefore flows from the mobile app to the gateway, and the gateway is the piece that actually touches the machines behind the router. That is why a gateway has to stay running on the network, and why the number of installed components grows if you decide to operate your own server. ## Getting the pieces in place and pairing a gateway by QR code There is no install script or package manager command in the README, so the setup is a download and a pairing exercise rather than a typed sequence. The Android, Windows, Linux and Darwin versions of the app come from the OpenIoTHub releases page, while the iOS version comes from the App Store listing. The gateway program for Windows, Linux and Darwin comes from the gateway-go releases. The server component, for the optional self-hosted path, comes from the server-go releases. For the first real use, the shortest path is the built in gateway. The app also has a built in gateway that provides a QR code addition method, so you can scan the gateway QR code to add a gateway without typing addresses by hand. After that, the gateway list, the remote host in LAN list, the remote ports in LAN list and the remote mdns service view are the four places the client expects you to work. Configuration saving is supported, and the old configuration can be loaded directly before the next startup, so a working setup survives a restart of the app without re-pairing. ## What the client actually forwards once a gateway is registered The supported feature list is the real product surface, and it is wider than a plain web proxy. The client can open an intranet website port directly, which covers the common case of reaching a router admin page or a self hosted service on a high port. It supports SSH terminals with direct access to the intranet, and file access via intranet SSH for both upload and download. A VNC desktop of a machine on the intranet can be opened directly, and a mobile phone RDP client can be called to open the desktop of an intranet Windows machine. There is also protocol mapping for FTP, offline download of aria2 using the intranet directly, and network boot through WOL for waking a machine before you connect. On the IoT side, discovery and control of smart home devices is marked as supported, though the linked device list is a separate repository. One line in the checklist is still open: directly back up the address book to the private cloud is unchecked. Treat the private cloud side of the project as a roadmap item rather than a shipped feature. ## Peer to peer transport, IPv6 and mDNS are where the friction shows Transport choice is the defining decision here. The client supports ipv4 p2p and ipv6 p2p, so the two endpoints negotiate a direct path rather than relaying traffic through a third machine. The benefit is that no always-on public server is required for the common case. The cost is that the handshake has to succeed, and the README does not document any relay fallback for the case where it does not. The self hosted server component exists as a separate path, but the documentation describes it as high level, so treat it as an escape hatch rather than a documented recovery procedure. Discovery follows the same philosophy. The client exposes a remote mdns service view, which means the gateway needs to see local broadcast traffic to find services that only advertise on the LAN. On a flat home network that is easy. Across a VLAN-segmented or heavily filtered network, the gateway list is the more dependable route, and even then the app keeps a remote host list and a remote ports list as a manual fallback. For readers comparing approaches: the repository topic tags include frp and nps alongside the p2p wording, but the OpenIoTHub documentation gives no detail on how those relate to the shipped transport, so any comparison you make should start from the p2p versus self hosted server split described above rather than from the tags. ## Release cadence, licence and the cost of running it The build history gives a clear picture of the project size. Recent tagged builds are v1.3.92+447 on 2025-08-12, v1.3.93+448 on 2025-08-21 and v1.3.94+449 on 2025-08-23, so the versioning uses a semantic base plus a build counter. The last push was on 2026-04-13, which is well past the date of the newest release listed, and that gap between the release tags and the last push is worth noticing when you plan an upgrade. The repository is not archived and is not marked for deletion. Licensing is MIT, and the repository carries a LICENSE file plus a separate PrivacyPolicy.md, which is typical for an application that distributes to mobile stores. The MIT terms are permissive for internal and commercial use, and the LICENSE file is the place to confirm what you are agreeing to rather than taking a summary as legal advice. The running cost is not licensing but uptime. A gateway has to be continuously running on the LAN for the tunnel to be reachable, and the optional server adds a process that needs its own port and secret key plus a public network address. The documentation is bilingual, with a Chinese README and a video course hosted on BiliBili, which is useful if the English README feels thin on operational detail. ## Conclusion Adopt OpenIoTHub if you already run a machine on the network you want to reach, you are willing to keep a gateway process alive there, and your WAN address changes often enough that static port forwarding is not an option. Do not adopt it as a team remote access system, a production VPN replacement, or a device management console: the client is a Flutter application, the feature checklist still has an open item for private cloud contact backup, and the release history is short and irregular. Before anything else, check the last push date against the date of your own evaluation, confirm that the peer to peer handshake succeeds on your specific network, and read the port and secret key requirements for the self-hosted server component before you commit to the extra moving part. ## FAQ ### What is OpenIoTHub and what does it let me do? It is a client for remote access to network services behind a NAT or firewall using p2p transport, aimed at reaching machines and IoT devices on a network you control. The README also describes it as a free IoT platform and private cloud platform. ### Do I need a separate OpenIoTHub Gateway to reach my home network? The gateway is described as continuously running on the LAN to receive access requests, and it is published separately for Windows, Linux and Darwin. The app also has a built in gateway that provides a QR code addition method, so a separate install is not always required. ### Is a self hosted OpenIoTHub Server required? No, the server is marked as high level and not necessary for the common user. If you do run it, the documentation says it should be configured with its own port and secret key, and the gateway can then use it with the information and public network address you configured. ### Which protocols can the OpenIoTHub client forward? The supported list covers direct opening of an intranet website port, SSH terminals, file access over intranet SSH for upload and download, VNC desktops, an RDP client for intranet Windows desktops, FTP protocol mapping, offline aria2 download over the intranet, and WOL network boot. ### How do I add a gateway to the OpenIoTHub app? The app scans the gateway QR code to add a gateway, and the built in gateway provides that QR code addition method. The client then shows a gateway list, a remote host in LAN list, a remote ports in LAN list and a remote mdns service view. ### Is OpenIoTHub still being updated? The repository is not archived. The last push was on 2026-04-13, while the newest listed release is v1.3.94+449 dated 2025-08-23, so check the release page for builds newer than that tag before you plan an upgrade. ## Sources - [Issues](https://github.com/OpenIoTHub/OpenIoTHub/issues) - [License: MIT](https://github.com/OpenIoTHub/OpenIoTHub/blob/main/LICENSE) - [OpenIoTHub/OpenIoTHub on GitHub](https://github.com/OpenIoTHub/OpenIoTHub) - [README](https://github.com/OpenIoTHub/OpenIoTHub/blob/main/README.md) - [Releases](https://github.com/OpenIoTHub/OpenIoTHub/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openiothub-openiothub