awg-manager: a web interface for AmneziaWG tunnels on Keenetic routers

A tunnel manager that lives on the router

AWG Manager is an AmneziaWG tunnel manager with a web interface for Keenetic routers, and the design decision is in the name of the deployment target rather than in the feature list. It runs on the router, and it manages the tunnels the router itself hosts.

The reason to do that is that a home router is where the wireguard interface already lives. Running the manager on the router means the tunnels it creates are the router's own, with the Keenetic system interfaces for wireguard, and there is no separate box to keep alive, no port forwarding to configure for the management plane, and no second set of credentials to protect.

The requirement is correspondingly narrow. You need a Keenetic router with Entware support and the wireguard component installed, which is the package manager that makes a Go service with a web interface installable on a consumer router in the first place.

Sing-box support was added in test mode, with the vless over tcp, hysteria, and trojan protocols named, and the project is explicit that AmneziaWG and Sing-box are used as transport protocols rather than being integrated with their own projects. The disclaimer is in the README as well: this is an independent open source project, not affiliated with Amnezia.org or with the Sing-box project at SagerNet, and not their official product. It also says the program is in a permanent beta stage, which is a phrase that means something specific here, since the release history shows the same thing.

The project is written in Go, MIT licensed, and not archived, with the last push on 2026-10-22. The releases are v2.19.18 from 2026-10-19, a development build published under the name latest on the same day, and v2.19.17 from the day before, and the default branch is develop rather than master.

What the interface actually does

The feature list is short enough to read as a description of the whole tool.

Tunnels for AmneziaWG and for Sing-box are managed through the browser. Peers can be added, removed, and monitored. There is a speed test with a real time display, and a traffic graph with periods of one hour, three hours, and twenty four hours. The tool can create AmneziaWG servers directly on the router.

The routing part is the most substantial. There is DNS routing through the tunnels, with support for the Keenetic NDMS system wireguard interfaces and for the Sing-box rule system, and there is a real time view of the connection status. The compatibility note says it works with Keenetic when using Entware, which is the package manager requirement again.

The graph with three periods is a detail that says something about the intended use. An hour is for watching a tunnel while you work, three hours is for a working session, and twenty four hours is for a daily report. That is a monitoring surface for a home connection, not an operations console for a datacentre, which is consistent with everything else about the project.

The repository layout matches that scope. There is a frontend directory, a cmd directory for the entry points, an internal directory for the implementation, an awgmproto directory for the protocol, an entware directory for the package build, a prebuilt directory, a scripts directory, a tools directory, and a vendor directory with the dependencies committed. There is an OpenAPI description, a profiling document, and a Go module that pulls in the coder websocket library, the MCP Go SDK, the protobuf runtime, a TOML parser, and the standard network and crypto libraries.

Installing it with opkg and busybox wget

The installation instructions are written around the constraint that a router has very little memory and very little tooling, and the choice of installer follows from that.

The stable install does not require curl. The installation uses the built-in busybox wget, which is useful on devices with small internal memory.

opkg update && opkg upgrade
wget -qO- http://repo.hoaxisr.ru/install.sh | sh

The alternative goes through GitHub over HTTPS, and it needs curl, because the busybox wget in the router firmware may not support HTTPS.

opkg install curl
curl -sL https://raw.githubusercontent.com/hoaxisr/awg-manager/develop/scripts/install.sh | sh

After the install, the web interface is reachable at the router's address, usually on port 2222.

The contrast between the two commands is worth noticing. The first one fetches a script over plain HTTP from a project domain and pipes it into a shell, which on a device that cannot verify TLS is a deliberate compromise, because the alternative would be an install that cannot happen at all. The second one uses HTTPS from GitHub, and it costs you a package install first.

If you are the kind of operator who cares about the difference, the second is the one to use, and the first is the one that will work on a device where the firmware's wget cannot do TLS. Either way you are running a script you have not read as root on a device that holds your home network credentials, which is the trade this project asks you to make.

Removal is equally simple, and it is specific about the leftovers.

opkg remove awg-manager
rm -rf /opt/etc/awg-manager /opt/etc/awg-manager.pre-restore-*

The pre-restore directories are copies of the data directory left behind by restore from backup in versions before 2.19.10, and they are called out separately because they hold your tunnel configuration and are not removed by the package manager.

The MCP server, and the tools that change the router

AWG Manager can expose its functions to AI agents, with Claude Code, Cursor, and Claude Desktop named, over the Model Context Protocol.

The setup has three steps. In the settings, the MCP server entry is enabled. A key is then created, and the key is shown only once, with ready made snippets for the clients on the same screen. The client is then connected with a command that adds the server over HTTP transport, pointing at the router and passing the key as a bearer authorization header, or through KeenDNS with a domain and a path for the same endpoint.

Access is by key only, even when the web interface's own authorisation is switched off, and the tool set is deliberately split by risk.

The read side covers the state, the logs, the tunnels and the routes, and the safe changes are starting and stopping tunnels, and the DNS, static and client routes, and the Sing-box configuration. There is also routing analysis for a domain or an address, checking the external IP through a tunnel, viewing the proxies, the subscriptions, the server groups and the Sing-box routing rules, enabling and disabling subscriptions and changing their mode and server, and managing the clients of the built in wireguard server.

A key can be issued read only, in which case any tool that would modify the router is refused. What is not available over MCP at all is tunnel deletion, backups, updates, and file access.

One operation is called out separately because it is the exception to the pattern. Deleting a routing list, whether DNS or static, is available, it is irreversible, and it is not recoverable through MCP, so the client marks those tools as destructive and usually asks for confirmation.

The key is the only thing protecting the endpoint

The documentation is unusually blunt about the security of the MCP interface, and the reasoning is worth following in full, because it explains a design decision that would otherwise look like a bug.

The key is the only protection of the endpoint from the outside. The attempt limiting works only for clients from the local network. Through the KeenDNS reverse proxy, all remote clients arrive from the address of the proxy itself, which is the loopback address, and counting by IP there would not protect anything, because any remote client could block the others with a few wrong keys.

The consequence is that for loopback requests the attempt limit is not applied at all, and protection against brute force from outside comes from the length of the key, which is 256 bits. The guidance that follows is to store the key as a password and revoke it as soon as it is no longer needed.

That is a coherent design, and it is a realistic one: the alternative would be to lock out the legitimate user, which for a router management interface is worse than a long key. It does mean the key is a bearer credential with no second factor, so the length is the only thing standing between an attacker and your router.

The second warning is the one that should decide whether you enable this at all. The key gives access to the VPN private keys. The tool that exports a tunnel configuration returns the whole configuration, including the private key. So anyone who has the MCP key, and any agent you gave that key to, can export the private keys of every tunnel on the router. The guidance is to issue a key only to clients you trust as much as the router itself, and to prefer a read only key where that is enough.

For most operators the right answer is to enable the MCP server, generate a read only key, and leave the write capable key out of the picture until there is a concrete need for it.

An independent project, and how it is funded

The section about the project is short and exists to make the relationship with the upstream projects unambiguous. AWG Manager was created as an independent tool for managing AmneziaWG and Sing-box tunnels directly on the router, without a command line interface. It is not affiliated with Amnezia.org, it is not developed or supported by the Amnezia team, and it is not affiliated with SagerNet nor supported by them. AmneziaWG and Sing-box are used as the transport protocols.

The community channel is a Telegram group, and the funding section is unusually informal, describing the project as always having a new bug and asking for donations in several currencies, with addresses for USDT over Ethereum, USDT over Tron, a Boosty page, and two YuMoney links, one of which is a general contribution and the other a recurring one.

The links section points at three other projects for people who want to set up or manage an AmneziaWG server, one of them an installer, one a multi script manager, and one a Docker image for the server, plus the project documentation site.

The technical shape of the repository tells the rest of the story. There is a vendor directory, so the dependencies are committed and the build does not need the network, which is the same constraint as the installation. There is an entware directory for the package build, a prebuilt directory for the binaries, and a kmod directory, which on a Keenetic means a kernel module, and the profile document suggests that the performance of the data path is something the author has actually measured and cared about.

The licensing is MIT, there is a changelog, a contributing guide, a version file, and an English version of the README alongside the original.

Editorial conclusion

awg-manager fits a Keenetic owner who runs AmneziaWG or Sing-box tunnels on the router itself and wants a graphical interface for peers, routing, and traffic instead of editing configuration over a terminal. It does not fit a router without Entware, and the MCP server deserves careful thought before you enable it, because the key it issues gives access to the private keys of every tunnel on the device. Verify first that the router has Entware and the WireGuard component, that you install over the transport you trust, since the stable install path is plain HTTP while the GitHub path needs curl for HTTPS, and that you treat any MCP key you issue as equivalent to handing over the router.

Frequently asked questions

Official sources

1. hoaxisr/awg-manager on GitHub
2. Issues
3. License: MIT
4. README
5. Releases