OnlyOffice and NAT…?

Hi.

tl;dr

I NAT’ed my Nextcloud box, and now OnlyOffice doesn’t work. Any help gratefully received. Thank you.

more

Is anyone running OO with NAT? If so do they have any suggestions, please?

The OnlyOffice container is running on the same host as Nextcloud. I’m using a Let’s Encrypt wildcard cert for my domain.

Nextcloud works fine. OnlyOffice was working fine …but I didn’t like having the server directly addressable, so I NATed it behind a private IP.

I read this, and I’ve tried solutions #1 and #3 here i.e.

  • editing /etc/hosts in the container to add “{private IP} mydomain.com”
  • creating an iptables NAT rule on the host

…but no joy: I get “503 unavailable” :frowning:

Thank you in advance.


Nextcloud version: 29.0.8 (all apps up to date)
Operating system and version: Ubuntu 20.04
Apache or nginx version: Apache 2.4.41
PHP version: 8.1

I think both the user and the Nextcloud must be able to reach ONLYOFFICE. Normally, a reverse proxy is used under certain circumstances.

Can you perhaps make a drawing of what your configuration really looks like? Can you possibly use a reverse proxy like nginx? There should be some instructions for this.

Normal NAT (at home) is no problem if Nextcloud server and ONLYOFFICE is in the internet. If you only have one server on the internet, you would then route Nextcloud and ONLYOFFICE via a reverse proxy.

Hi devnull, and thanks for responding :slight_smile:

Can you perhaps make a drawing of what your configuration really looks like?

Sure; no problem.

In hardware terms:

In application terms:

In connection terms:


There are separate virtual host files (in Apache) for Nextcloud and the OnlyOffice instance. The latter is proxied via ws://localhost:8080. In both cases the “VirtualHost” directive of the file uses the NATed i.e. private IP of the server.


I NATed the server a week ago. Nextcloud still works fine; OnlyOffice doesn’t work any more :frowning:

Any help would be much appreciated.

So you just run Nextcloud on the local network. What is the NAT part for? Just use a local DNS resolver that resolves Nextcloud’s hostname to the local ip of the Nextcloud server.

Just use a local DNS resolver that resolves Nextcloud’s hostname to the local ip of the Nextcloud server.

You’re suggesting I run (e.g.) BIND?

The Nextcloud instance is accessible to the WAN (“externally”, if you like) as well as to the LAN (“internally”). Until recently, it was served directly from its static public IP. But that’s suboptimal: it’s better for it not to be directly addressable from outside. So I configured the firewall to NAT the static public IP to a local (i.e. RFC1918) address, as a matter of good practice.

If anyone else is running NATed instances of Nextcloud and OnlyOffice, I’d welcome their suggestions.

Thank you.

How do you address it now from outside, you still need to forward the port or something like that, and with that expose the port to the outside, no? In your design, why not use the official ip, and then use the firewall to restrict the ports?

With ipv6, that is one of the advantages that you can go back to the initial approach on the internet that you can have point-to-point connections, and not five times NATed connections and simplify your life. Especially that many consider NAT not a security feature.

How do you address it now from outside

Address what? OnlyOffice?

Via Nextcloud: the app connects the docker container to your NC instance.

you still need to forward the port or something like that

See above: the container is proxied via port 8080.

and with that expose the port to the outside, no?

Forgive me - I’m not sure what you’re asking here(?)

In your design, why not use the official ip

By “official”, do you mean the public IP?

[…] and then use the firewall to restrict the ports?

Yes, that’s what the firewall is doing (…amongst other things); that’s the idea.

With ipv6, that is one of the advantages that you can go back to the initial approach on the internet that you can have point-to-point connections

Well… “discuss, 20 marks” as they say! Just because it’s possible to route all the way from one LAN to another across the Internet doesn’t necessarily mean it’s desirable to do so. IPv4 isn’t going away any time soon, so dual stack connectivity is going to be a reality for the foreseeable. Which means the potential for fun things like unintended routing due to DNS disparities. But I think we might be veering off the subject a bit…