@tamorgen you could try the canonical CIDR notation of 192.168.1.0/24 and see if it makes any difference (replace last 1 with 0)

@toggledbits thanks, this is exactly the behavior I'm seeing. Not going to go that iptables route, but need to check if that X-Forwarded-For is the answer.

@toggledbits here you go:

http://192.168.1.12:8111/api/v1/log

I'm trying to allow anonymous access from a local network to /api/v1/log, but the problem now with the reverse proxy configuration is that this access is open via proxy to the internet. At least I wasn't able to configure ACL so that only an access from a local network would be permitted.

reactor.yaml:

baseurl: "http://192.168.1.12:8111"
proxy_baseurl: "https://external.com:30000"  
trusted_proxy: "192.168.1.12"  

Local traffic would originate from 192.168.1.0/24 network. Synology is acting as a reverse proxy and hosting MSR as a docker container (which has its own network and IP 172.18.0.5). MSR build is latest-26298-fbb75fb8

users.yaml:

- url: "/api/v1/log"
    method: "GET"
    source_ip: 172.18.0.0/24 
    allow: true

Using the above ACL works, but it enables access via proxy also. If I use source_ip: 192.168.1.0/24, then it doesn't work either locally or remotely. So I'm kinda lost what should I use as source_ip in this case?

@toggledbits thanks again for the reverse proxy support! I was wondering whether MSR's login functionality could be further secured, for example by implementing features similar to those Synology uses for DSM (see below).

@toggledbits, did follow your instructions and now reverse proxy works like a charm, thanks! I'm using https on Synology and firewalling functionality (allowing based on geo-ip), further restrictions done in Access Control Profile that DSM offers in reverse proxy configuration. Obviously also using authentication in MSR.

@therealdb what's your baseurl setting? Especially are you using different external port (and not 8111)?

@therealdb although I used only IP addresses and not dns names, I wasn't able to get UI to load. In my setup I'm using MSR in a docker container network and not host networking, so that might cause some additional headaches.

So could you share your configuration (e.g Synology reverse proxy conf, baseurl ...)? Obviously no need to use real IPs. I'm also wondering if https configuration in MSR can be avoided (not using that at the moment), but using let's encrypt cert in DSM. Port forwardings & firewall settings shouldn't be an issue, as /api/v1/log page works fine.

(MSR itself being in a container network having 172.18.0.11 address)

@toggledbits if I’d put public IP there, would it still work as expected when UI is used without a proxy? Also, does it accept dns name or just IPs?

@toggledbits yes I have

baseurl: "http://<private ip>:8111"

I'm trying to use MSR via reserve proxy in Synology DSM, but MSR page does not load

https://<public ip>:30000/reactor/en-US/

At the same time logging page loads normally

https://<public ip>:30000/api/v1/log

I thought maybe authentication was messing it up, but there was no deny entries in the log, and also disabling authentication did not make any difference. For this use case VPN is not an option (that works, but as said not an option for this particular use case).

Any ideas what could cause this? MSR build latest-26242-28d69aa8, Chrome browser

@noelab are constraints also true (or empty)?

A while ago I got rid of my Hubitat, so I'm no longer updating this thread

@tbully maybe not that helpful comment, but I strongly recommend docker (builds)

@toggledbits ...Revisiting this briefly, and a humble request for you to consider.

I'm still struggling with this particular solar inverter that's acting in a non-standard manner (against RFC 7616). Given this behavior, I would like to ask for the following changes to the HTTP request handling:

• If the server returns the header x-www-authenticate, it would be treated equivalently to www-authenticate
• If the server specifies algorithm="SHA256", it would be interpreted as algorithm=SHA-256 (and there might be even extra whitespaces present, e.g. " SHA256 ")

@toggledbits great work, as always!

@toggledbits I have, but it's a bit complicated setup (a proxy in between because of earlier problems with x-www-authenticate & www-authenticate headers). Related to Fronius inverter firmware update (some people have discussed this problem e.g. here)

I'm considering using modbus tcp (in home assistant) instead of http request, as this is getting tricky.

@toggledbits amd64 (synology nas)

...another thing, has ping command been removed?

With build 26140 (on Docker) I'm not able to clone any actions in reactions. Using Chrome if it has any relevance.