Hello,
to outline my setup: I am running Nextcloud AIO locally. It is reachable from public by an nginx reverse proxy that forwards all traffic through a VPN. In general, that works like a charm.
There is just one thing that I am yet not able to grasp.
When opening an office document I get some WOPI error. In the logs it says:
WOPI request denied from <public IP of my local DSL connection> as it does not match the configured ranges: 127.0.0.1/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, fd00::/8, ::1
That is quite clear, although I am wondering why my public IP shows up here. If I got it right, the WOPI requests come from the local Collabora Server.
So I checked the configuration in the Office section:
The “URL used by the browser” makes sense to me, the second one makes me think I found my problem: if Collabora is requesting documents from Nextcloud through the public reverse proxy it will indeed due that via my public IP. But actually, it would not need to go that way because the Collabora container is running right next to the Nextcloud one?
Adjusting URL (and Port) of Collabora Online-server to the local address of the Collabora server did, as expected, not change anything.
The obvious solution is to simply allow WOPI requests from everywhere as my public IP isn’t static and keeping it up-to-date in the allowlist isn’t feasible.
Therefore, it boils down to two questions on which I would really like your advise:
The text aside the allowlist field suggests that it’s insecure to allow requests from everywhere. But is that actually the case? After doing some searches, I am under the impression that these WOPI requests towards Nextcloud contain some token - so allowing all IPs to make requests wouldn’t actually be a problem because an attacker couldn’t provide a valid token?
Can I configure Collabora to make its WOPI requests to the local container IP of Nextcloud instead of going the long way through the reverse proxy without messing with AIO?
this is exactly how the WOPI protocol works. Connections always use public FQDN which usually results in going through the public internet as long there are no special measules like splitbraindns (101: Split-Brain DNS (split-horizon)) are in place.
yes the connection is secured with a token. limiting network ranges adds additional security layer which might or not be required for your specific installation.
Hello @wwe ,
thanks a lot for the explanation and for the linked integration guide, the second diagram kind of made it clear to me why it makes sense to use the FQDN. Though, I don’t really see a technical necessity. But if that is how it’s specified, I am fine with it
I guess I don’t need that additional security, the token is sufficient for me. Not worth the effort for fiddling with the DNS.
Just one thing that I think is a little odd: the default value for the allow list only contains private/local addresses. So without additional measures like split-brain DNS etc. this should never have any effect?
