Swag Nextcloud Docker reach internal IP

Hi all,

I configured my Nextcloud docker container with Swag and DuckDNS following these Techno Dad Life videos:

Video 1:

Video 2:

Everything is set up and working fine when I connect via the public URL. However, after setting up Nextcloud in the local network only (video 1), I was able to reach Nextcloud on its local IP (192.168.0.101:444). After installing Swag and DuckDNS (video 2), the local IP will give me ERR_CONNECTION_REFUSED.

The issue is that now whenever I upload something from my local PC, it is apparently routed through the internet, which is slow and unnecessary.

Does anybody know if it is possible to make local IP and public URL working at the same time (and how to configure this)? Or any other way to prevent the local traffic from being routed through the internet?

Thank you in advance!

Cheers

First of all, thank you for your responses and sorry for my late reply. Somehow I thought I'd get email notifications - doesn't seem to be the case

I will try to re-configure the DNS accordingly. I keep you posted about it. I hope to be able to make some time during the holidays.

Of course, long-term there'll be no way around upgrading.

So after contemplating I believe there's no way to manage this in my current setup. The issue is that calling the new external port (450) directly leads me to a default page of Swag. I suppose Swag behaves this way to prevent bypassing the proxy (blocking anything that doesn't come via DuckDNS), so it's a security feature that I definitely don't want to switch off.

Until upgrading one day (or until someone comes up with an awesome solution I will live with it.

Thanks again for your responses.

chente

Zitat

I solved it by installing a DNS server on my router. That way I access Nextcloud from LAN with the domain.

Unfortunately this is not possible with my router. And even if – I assume I would just see the SWAG default page again (same as when calling 192.168.0.101:450 directly).

KM0201

Zitat

Near the end where I put the "this is optional" step to comment out port 450... just don't do that, and you'll have unsecured local access and secured remote access.

I remember, this is what I tried in the very beginning, as well. I'm using an OMV Docker plugin, i.e. I have a GUI where I configure the port forwardings (see screenshot with 444 as an example). However, whenever I try to set a port forwarding rule for the nextcloud container and click "+" and "Save" it is just ignored. Probably this is the actual problem The docker logs for this container don't show any errors.

Hi guys,

I'm on OMV 6 now I'm also aware it's not 100% stable, but currently I'm fine with this.

Thanks to KM0201 I managed to set up Nextcloud and Swag again I left the part with

"ports:

- 450:443"

uncommented.

This means compared to the old set up I changed the ports as follows (equal to those in the manual mentioned above):

192.168.0.101:443 --> OMV admin interface

192.168.0.101:450 --> Nextcloud

<MY_EXTERNAL_IP>:443 --> Nextcloud

However, the original problem (local connection to Nextcloud is quite slow in uploading data) persists.

I've tried to set a so-called DNS-Rebind-Protection in my router with nextcloud.MYDOMAIN.duckdns.org. This didn't help.

The general issue with DNS is that I can't set the required port (as DNS doesn't understand ports afaik). This made me wonder how chente accomplished this with DNS? Did you change your OMV admin interface port?

Does anyone have another idea on how to solve this?

Also, I'm a bit unsure about my way to "measure" the connection. What I currently do to find out if it works is:

- Uploading an example file to Nextcloud (and seeing that it's slow compared to SMB). But it could be that Nextcloud itself is just slow in accepting the uploaded data.

- And: tracert nextcloud.MYDOMAIN.duckdns.org

Getting:

1 1 ms <1 ms <1 ms fritz.box [192.168.0.1]

2 1 ms 1 ms 1 ms XXXXXXXXX.dip0.t-ipconnect.de [<MY_EXTERNAL_IP>]

Maybe someone can tell me if this is a reliable way to detect the routing?

Thank you

Zitat von chente

Exactly. I access the OMV GUI through a different port. This is configured in the GUI under System > Workbench >

That did the trick, thanks.

So:

- I configured the "hosts" file of my local PC to point nextcloud.MYDOMAIN.duckdns.org to the local IP 192.168.0.101

- The nextcloud docker container is configured to listen to 443

- The OMV GUI is moved to a different port (also not 80)

With the result:

- My local PC communicates with Nextcloud (browser & client) only via local network (with an invalid certificate, but that doesn't bother me):

1 1 ms 1 ms <1 ms nextcloud.MYDOMAIN.duckdns.org [192.168.0.101]

- Other devices in the local net communicate securely over the internet (or at least the server of my ISP)

- Remote devices communicate securely over the internet

- btw "tracert" seems to be a working way to detect the route

The speed is only a bit higher than before though Nextcloud itself seems to be the bottleneck now. At least the data from my local PC is not routed through my ISP anymore.