Nextcloud + Office Online + HA Proxy (or other reverse proxy) problems when public FQDN used

Hi community.

We have an installation of Nextcloud 21.0.1, with the connector for MS Office Online 2019. The Nextcloud instance is accessible both from the local intranet and on the Internet (using HA Proxy).
Apache2 is used as a webserver, with SSL certificates issued by the RootCA of the local intranet.
And HA Proxy is configured with SSL certificates from Let’s Encrypt, for correct HTTPS access from the outside.

However. When we access Nextcloud using the local intranet URL, https://cloud.intradomain.local/, everything works perfectly: we can open and edit any document from Word, Excel, etc. The problem occurs when we access Nextcloud using the public URL (it does not matter if we are inside or outside the local intranet), when this is the case, no Office document can ever be opened, and we always get an error message like “Unable to Open the file”.

We think that we should touch some configuration in the reverse proxy HA Proxy, but we are not sure what to modify there.
Or maybe change something in the IIS instance … but IIS is a weirdo when you come from the Apache/Unix world.

We have tried changing the DNS resolution (by editing C:\Windows\system32\drivers\etc\hosts file) on the MS Office Online document server, so that the public address is resolved to the local IP of the Nextcloud server, but without success.

Any ideas / help you can give us?
Keep in touch.

Did you allow the public domain on your OOS server ? Get-OfficeWebAppsHost (OfficeOnlineServerPowerShell) | Microsoft Docs

Hello @Steel_PC .
No configuration set about that. I was also unfamiliar with the cmdlet.
On the document server, I tried to run it, but saw that there is no configuration set, which according to the documentation means that anyone could use the document server.

PS C:\> Get-OfficeWebAppsHost


PS C:\> Get-OfficeWebAppsHost | Select allowList -ExpandProperty allowList
PS C:\>

I have also seen that there is no Set-OfficeWebAppsHost cmdlet …
Anyway, if the document server really allows connections from any origin, I don’t think that’s the problem … even so, I would like to know how to restrict that list.

Your can secure that with New-OfficeWebAppsHost (OfficeOnlineServerPowerShell) | Microsoft Docs
You need to reboot or restart the oos service after setting a new host.

Here is the command I use to start my oos (ssl terminated and load balanced on haproxy) → New-OfficeWebAppsFarm -InternalUrl “http://oos.myinternaldomain” -ExternalUrl “https://oos.myexternaldomain” -SSLOffloaded -EditingEnabled

Is the url https://oos.myexternaldomain/hosting/discovery reachable from inside and outside your network ?

Also all external domain url should be set to your local IPs in your global dns. Everything should point to your Haproxy IP.

Last but not least the url in your nextcloud connector should be the external url of your oos server not the internal.

1 Like

But I have a doubt with that. Why does the document server also need an external address? I thought that if only Nextcloud had an external address, that was enough, and then Nextcloud and Office Online communicate internally, using their internal addresses.
In Nextcloud, the document server address is set to https://oos.myinternaldomain/hosting/discovery

And yes, I had thought at some point, expose the document server to an external address, and configure Nextcloud to use the external address…

Even so, when I have configured HA Proxy to expose the document server using an external address, but for some reason that I do not know as much as IIS, I cannot access it. The Windows event viewer leaves a lot to be desired, it does not report anything relevant. And this is the only web service that does not work with HA Proxy; all the other services we have have no problems … but of course, they are Apache2 and nginx servers, not IIS, so I suppose it is something related to IIS.

From what I see here, I have two problems:

  • On the one hand, to determine if it is necessary for my document server to have its own external address (apart from Nextcloud’s). If the answer to this is yes, then I have to get to work on that.

  • On the other hand, if an external address is not necessary for the document server (which was my initial guess), then it only remains to find out why Nextcloud works well when I use its internal address, and why when I use its external address, the office cannot be opened.

Some clue? / Any help?

I think your problem lies in the way you start your oos server. Which command do you use ?

Is haproxy terminating your ssl connection to your oos server ? On your dns (client machine) is the oos ip the one of your haproxy ?

You have too many components involved. A little bit more information would be valuable to help you.

If I read correctly point 4 of the wopi doc nextcloud is just calling the oos server into an iframe so it does need a reachable external address to work from outside your network

This does not explain why it’s not working with your external nextcloud address from within your lan though

I can internally access http: //oos1.localdomain/hosting/discovery and even http: //oos1.localdomain/ (which, hopefully, responds to an IIS 404 error page).

Now, when I access from the outside, to https: //oos1.externaldomain/hosting/discovery or I try with https: //oos1.externaldomain/ nothing happens. Nothing at all.

curl -i https: //oos1.externaldomain/

It does not answer anything. (Timeout). As if the host did not exist. But it exists.

So, just for the purpose of testing that the problem does not lie with the HA Proxy configuration, I change the backend used for that frontend to a test http server, which is externally accessible.

And, my problem is (for now) in HA Proxy. :face_with_raised_eyebrow:

So I’ll try to fix that part, and then (when my document server is finally accessible from the outside), I’ll comment on the results.

In the meantime, thank you very much for your help.
We are in contact!!!

Yes 404 on anything else than discovery is normal behavior :slight_smile:

Don’t forget that your oos server has to be configured to be called by an external domain name or else it will not respond. Thus I would check the command used to create the oos farm before doing anything else.

Haproxy is pretty straight forward on this and doesn’t require any specific conf other than the one your already use for you nextcloud server.

Hi! Me again…

Well, finally, I was able to properly configure external access to the document server.
I even enabled the opening of documents via the web:
Set-OfficeWebAppsFarm -OpenFromUncEnabled: $ true
which enabled me a nice web interface to open by link in the root of my coumentos server, also accessible from the Internet:

On the other hand, from Nextcloud, in the Office Online configuration, I indicate that the document server is located at https://office.externaldomain.tld/hosting/discovery and it works like a charm.

Now, if the access to Nextcloud is given using its internal URL via https://cloud.internaldomain.local/ I can edit documents.
But if instead, the access to Nextcloud is using its external URL, https://cloud.externaldomain.tld/ when trying to open an Office document, I always get some kind of error.
This, despite the fact that in the Office Online configuration, everything is always perfect:

I am, again, stuck. What other clue can you provide?

Best regards!

Stupid question again : Did you allow the external domain of your nextcloud on your OOS server ? Don’t forget to reboot after allowing or removing a host