Luci via reverse proxy

I'm trying to set up a reverse proxy on a remote (non-OpenWrt) server that'll sit in front of and reach out to Luci running on my OpenWrt mobile router, via wireguard, so that no matter where (or with what IP) my router happens to be, it's reachable remotely.

I've got it all almost working, with the exception of some jsonrpc calls to /ubus -- they appear to hang and time out. Reliably, the Status Overview page fails to load via reverse proxy, as well as the Network Interfaces page. For reverse proxies, I've tried Apache and HAProxy with the same results on both. For HTTP servers on the OpenWrt side, I've tried both uhttpd and nginx, again with the same results on both. Of course, directly connecting to Luci (not using the reverse proxy) works and all pages load normally. I'm running OpenWrt 23.05.0-rc1.

Any hints? Has anyone successfully done this before?

Welcome to the forum.

If you're intending to use WireGuard to establish a link between the reverse proxy and OpenWRT, why not just cut out the reverse proxy and use WireGuard to phone home directly from your device? What benefit do you believe having a reverse proxy will provide?

The reverse proxy is reachable on the internet from anywhere sans Wireguard client, which is quite handy.

Sorry about the noise, I've got this sorted out. Turns out it was as simple as completely clearing my browser caches.

1 Like

And also a gaping security risk, depending on what other security mechanisms you have in place. Do you really want your router's admin access open to all and sundry? Even if there's a password to log in, simply exposing the control plane to the Internet is generally considered unwise.

Ultimately the approach you take is up to you, but for my own setup I would never have any admin access open to the Internet, whether behind a reverse proxy or not. Admin access belongs solely inside private segments of the network.

It's never the DNS. Or the caches. :joy:


For posterity, I just wanted to note here: yes, it would be a gaping security risk to open Luci to the world like this. In my case, the security risk is largely mitigated by requiring SSL with client certificates verification.

My view is that relying on IP or network topology for security is insufficient at best and misleading at worst. My approach is to be able to make the same security assurances whether or not an adversary has access to “private” segments of my network. Or, put another way: there’s no such thing as a private segment of my network, in principle.

1 Like

Or, in even fewer words, "assume breach". It's a reasonable concept, and is the basis of the newfangled hip and trendy "zero trust" malarkey all the big security vendors are currently peddling. (If I sound ever so slightly cynical, it's because that malarkey is my day job...)

The traditional (better-) solution for this would be keeping the WAN interface closed for http/ https, but (only-) accessing it via a (roadwarrior style) VPN tunnel into your network, from the inside.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.