What is Zero Trust here?
Traditional network security assumes that anything inside your network can be trusted. Zero Trust flips that model: no request is trusted by default, even if it comes from inside the VPN.
In wireguard_webadmin, the Zero Trust application gateway sits in front of your internal services. Every request must authenticate before reaching the app — the service itself never needs to be exposed directly.
How a request flows
The public endpoint receives the request instead of the internal service.
Altcha proof-of-work can challenge automated abuse before login even starts.
Credentials, TOTP, and source IP policy are evaluated.
Only approved requests are proxied to Grafana, Proxmox, or another internal app.
Authentication methods
Anti-brute-force: Altcha proof-of-work
Before any login form is shown, the browser must solve a lightweight computational challenge (Altcha).
This has zero friction for real users (solved in milliseconds by modern hardware) but makes automated credential-stuffing attacks computationally expensive at scale.
Layered protection: Rate limiting is already in place. Proof-of-work complements it — where rate limiting bounds the request volume per IP, Altcha adds a per-request computational cost that makes distributed attacks expensive regardless of how many source IPs are involved.
Use cases
- Expose Grafana to your team without opening port 3000 to the internet
- Publish a Proxmox web console behind TOTP, accessible only from your VPN
- Share a self-hosted app with a client with time-limited credentials
- Gate any internal HTTP service without touching its configuration
No app changes required. The gatekeeper proxies the request transparently. Your internal service doesn't need to implement authentication — the gateway handles it.
VPN management and the application gateway run as a single self-hosted stack. No account at a third-party service, no outbound tunnel dependency, no traffic leaving your infrastructure.