I am unable to access my Nextcloud instance when connected to my home network. It’s running on a Raspi 4. Everything works perfectly fine if connected from another network or through a VPN, it’s only on this one network.
I’ve tried whitelisting it on fail2ban and removing the entry from oc_bruteforce_attempts in MySQL (there wasn’t any entry in there anyway), but it still won’t connect.
Can provide any logs that could be useful.
Thanks for the help!
You use your local ip? So there is no response or some error? You can ping the raspberry and login via ssh over your local network?
I’ll try and clarify.
My raspi is connected to a home router with an external IP of (for example) 123.456.78.910 which is redirected from a dynamic DNS. When I’m at home, and my laptop is connected to this same router via wifi, my laptop’s external IP will be the same as the raspi.
When my raspi sees an attempt to connect http or https from 123.456.78.910, it won’t connect (connection time-out), but it will work from any other IP (so when my laptop has a VPN running, or using a 4G hotspot). Any other device on the same network will also fail to connect.
It will however accept ssh connections through this external IP (using port forwarding like http and https, “ssh pi@123.456.78.910”).
Everything (http, https, ssh, ping) works fine over the local network.
Option 1. Check your router, it could be that you put your RasPI in DMZ or make accessible only via internet.
Option 2. Your iptables or other firewall on RasPI accept only connections from the router or external IP = you only comes via internet to it.
I think it may be an issue with the router, but I don’t have any control over the necessary settings. So I’ll need to call up my ISP about that.
Just start from the small:
- What is your RasPI IP inside of the network? e.g. 10.10.10.10
- Can you ping it?
ping 10.10.10.10 - Can you ssh to IP directly?
ssh user@10.10.10.10 - Can you call Nextcloud directly?
curl -v -k http://10.10.10.10andcurl -v -k https://10.10.10.10
Inside the network the IP is 192.168.0.217, and I can ping it and ssh in with no issues.
When calling Nextcloud using curl I get this:
~ $ curl -v -k http://192.168.0.217
* Trying 192.168.0.217:80...
* TCP_NODELAY set
* Connected to 192.168.0.217 (192.168.0.217) port 80 (#0)
> GET / HTTP/1.1
> Host: 192.168.0.217
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Mon, 27 Jul 2020 13:33:43 GMT
< Server: Apache
< Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
< Location: https://192.168.0.217/
< Content-Length: 206
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="https://192.168.0.217/">here</a>.</p>
</body></html>
* Connection #0 to host 192.168.0.217 left intact
~ $ curl -v -k https://192.168.0.217
* Trying 192.168.0.217:443...
* TCP_NODELAY set
* Connected to 192.168.0.217 (192.168.0.217) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=cloud.*********.fr
* start date: Jul 23 09:49:50 2020 GMT
* expire date: Oct 21 09:49:50 2020 GMT
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x559ad3fabdb0)
> GET / HTTP/2
> Host: 192.168.0.217
> user-agent: curl/7.68.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 302
< date: Mon, 27 Jul 2020 13:34:00 GMT
< server: Apache
< expires: Thu, 19 Nov 1981 08:52:00 GMT
< cache-control: no-store, no-cache, must-revalidate
< pragma: no-cache
< content-security-policy: default-src 'self'; script-src 'self' 'nonce-d2ZYcHZ4QU96VFVoa3ErWmwrQkRXM2lUK2dPZVFRamRvaHZFOExTV1hFND06OUtTbDJFWjJsWDEweXY3cjBOZzJMdy9TcjBick5ER3Q3elN6c2ZQUkVRcz0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
< set-cookie: ocrnfg5r4p1o=ipb9jj03gk41gs0cq4vo39804t; path=/; secure; HttpOnly
< set-cookie: oc_sessionPassphrase=%2Fc8fMQqPw2d0wesPRD7M0u85jh7FOMsG2MlHvk4SiKkEbe3k%2BhWp5SYSbjU1Haz4pKeXnc0ilg7jCqqRCX1%2B6kmji2%2BTNrl2%2BSl8sDhxMtIGTKiggkkre7tQOMmVW7wT; path=/; secure; HttpOnly
< set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
< set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
< strict-transport-security: max-age=15768000; includeSubDomains; preload
< referrer-policy: no-referrer
< x-content-type-options: nosniff
< x-download-options: noopen
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-robots-tag: none
< x-xss-protection: 1; mode=block
< location: https://192.168.0.217/login
< content-length: 0
< content-type: text/html; charset=UTF-8
<
* Connection #0 to host 192.168.0.217 left intact
~ $
Well, it looks good!
You can reach your RasPI under your LAN via IP Address, you see that Coockies are set from the nextcloud (with oc_ prefix) thats means it works! 
Only what is not working is your routing from the FQDN (what is cloud.***.fr) to your local machine from the LAN.
When you hit https://cloud.****.fr, your machine asks DNS that will bring your external IP (something like 92.123.123.123), it seems that when you are inside of the network your Router is not able to route his external IP to himself. Not sure how it is done in your ISP and particular Router…
You can try to edit hosts table on a Lunix/Win/Mac, e.g. added to /etc/hosts line 192.168.0.217 cloud.***.fr in this case local machine will not ask DNS anymore, but use hosts file instead and correctly route you to the RasPI.
You can use something like pihole this will give you opportunity to edit local DNS Centrally and associate your cloud.****.fr with your local IP 192.168.0.217.
Great thank you, I’ll see what I can do about that! Otherwise I guess just using the local IP will do if not using a VPN.