OK, I had some time in the past couple of weeks to look into this. Build 26284 now contains some changes that should smooth out configuration and use of reverse proxies. Let's see how it goes, and if I need to do more, we can work through that. There are a couple of new configuration keys to be used when a reverse proxy will provide access to Reactor, and a couple of existing keys have small (?) changes in behavior. The keys and behavior are summarized in the documentation for Access Control in the appropriate places, but to streamline the discussion and your efforts, I'll summarize them here. These configuration keys live in the reactor section of reactor.yaml.
First is trusted_proxy — this tells Reactor the host address of the LAN side of the reverse proxy. This is the address Reactor first sees opening the UI or API connection. The value of this configuration key can be an IPv4 address (e.g. 192.168.0.10). It can also be an array of addresses. I recommend surrounding the address(es) with quotes just to avoid any problems. When Reactor sees a request come in from this address, it looks to see if the request follows the HTTP/1.1 protocol for reverse proxied requests. If so, Reactor knows to track both the request source address (the inside address of the proxy) and the client address (the IP address of the client using the proxy to access Reactor, which may be inside or outside of the LAN). If those two addresses are different, Reactor knows its a proxy request.
Second is proxy_baseurl. This sets the URL to be used as baseurl when the request is proxied. If Reactor needs to redirect for the UI, it will use baseurl as the base of the redirect if the request is not a proxy request, and proxy_baseurl if it is proxied. Typically, users of reverse proxies will keep baseurl set to the internal (LAN) URL used to access Reactor (e.g. http://192.168.0.66:8111), but set the proxy_baseurl to the externally-resolvable URL for accessing Reactor from outside their network (e.g. https://example.duckdns.org:8554).
Proxied requests are processed a little differently by allowed_ips and ACL IP matching. When a request is proxied, the IP address matched by allowed_ips is that of the actual client, not the proxy's inside (LAN) address. Therefore, if you use allowed_ips with trusted_proxy, you must list every external/public host address (or network address in CIDR form) that is allowed to access Reactor through the proxy. By default, the proxy is not trusted by allowed_ips. That can be very inconvenient when you are a road warrior (frequent traveler to many places unknown) and want/need to access Reactor from wherever you may be. To help with this, at the expense of some security, you can tell Reactor that the proxy is trusted and all requests from the proxy should bypass allowed_ips filtering. Do this by setting pass_all_proxy: true, but if you do this, you must make sure that the proxy itself provides any and all filtering/authentication/security you might need before allowing access to Reactor. The pass_all_proxy key works only to circumvent the allow_ips list; it does not apply to ACLs.
Access control ACLs now have from_proxy to provide matching to requests coming from a specific proxy host (or network). The source_ip filter always looks at the client address. An analog for pass_all_proxy in ACLs could therefore be an ACL with from_proxy and allow: true (actual implementation depends on the full set of ACLs and their sequence).
Proxy configuration does not change any behavior of user access control in Reactor (i.e. Reactor user login). It is highly recommended that user login be configured and used when a reverse proxy is in use, even if the proxy provides access control in front of Reactor. If you choose not to use user login, you may be leaving your Reactor system vulnerable to external access by accidental discovery (e.g. port scans). Using user login with strong passwords provides an additional, necessary layer of deterrance to illicit access. Reactor will warn you if you are configured for proxy access without enabling and using user login.
The Reactor documentation recommends that you enable/use HTTPS when using user login/auth. You can get away without HTTPS if your access is exclusively on your home network (no external requests or reverse proxies), but it's a different matter when your login requests are going to be through public networks. Therefore, it is also highly recommended that you use HTTPS to access Reactor through your proxy. At the very least, your proxy should receive SSL/TLS-encrypted HTTP requests at its public/external interface. You can keep internal access to Reactor in plain, unencrypted HTTP (including requests from the proxy to Reactor) if you trust your internal network.
And for clarity, in all above where I say "highly recommended" I mean required unless you want to invite trouble.
To wrap up, a checklist:
- Set
trusted_proxy to the inside host/interface address of your reverse proxy;
- Set
proxy_baseurl to the externally-accessible URL used to reach Reactor through your reverse proxy;
- Enable and configure user authentication/login in Reactor if you haven't already;
- Make sure your proxy's public interface uses HTTPS (encrypted); HTTPS on the inside (between proxy and Reactor) is up to you.
Ref: Access Control in Reactor documentation
And a disclaimer: Opening up any system to the public Internet increases risk. Because the totality of your systems, tools, and needs are unique to you, only you can assess the risks of such access, and the correct and most secure way to provide it. Proceed at your own risk, and know that it is entirely at your own risk and that you accept that risk and its consequences in so doing. I am providing tools, not solutions. How you use these tools is up to you, and the consequences for not using any tool properly can be dire. If you don't know what you are doing in this area, don't do it. You've been warned.
