What should I look for? connection to nextcloud only fails from https outside the lan

[autotel]

context info

Nextcloud version: 16.0.3
Operating system and version Debian 9 (stretch)
Apache version: Apache/2.4.25 (Debian)
PHP version (eg, 7.1): PHP 7.2.22-1+0~20190902.26+debian8~1.gbpd64eb7
Domain name provider: duckdns.org
Firmware on the router: OpenWrt

this is my first experience hosting https, so there might be something obvious to everyone that I am missing.

The issue you are facing:

This is the first time I have seen this error. I was running nextcloud fine over http. In order to have it working well on both LAN and WAN, I installed openwrt on my router and then set it to forward HTTP into the host’s ip, but also to treat my public url as if it was that computer’s IP (honestly I don’t remember how I did that… I think I used nginx), in that way the same public address would work in the lan.

It worked fine until I started using https thanks to letsencrypt and certbot (just followed the tutorial). I also added the port forwarding of the 443 port. My apache server still works well over https. I have other static pages in the same server that display over that protocol. When visiting the nextcloud address, however, it just times out.

I have sought online a lot, but I don’t really know what the problem could be, so it is very hard to find good keywords to search. The info I have is probably not enough, but I would be thankful to receive suggestions on what could be wrong, or on how to check what causes the request to fail. I repeat, that I could be missing something obvious since I have never done nor seen anyone do this setup.

log:

While attempting to access the site from the wan, nothing appears in the log (I only get flooded with “You are using a fallback implementation of the intl extension.” errors, but installing that extension is a whole other problem, I really tried)

The output of your config.php file in /path/to/nextcloud
That file doesn’t exist! What was I supposed to do?

The output of your Apache/nginx/system log in /var/log/____:
Log named apache2 is empty. No log named apache.

[gas85]

@autotel

I think I used nginx

It could be that your ngnix try to terminate the TLS connection, but if you setup your nextcloud Apache2 as e.g. described here (or similar):

@gas85

Apache 2.4.18+ with Letsencrypt on Ubuntu 20.04 - SSL config for A+ on SSLLabs.com · GitHub

Then you will set Certificate pinning and after you visit your NC once your browser will not accept anymore what ngnix on Router does.

Try to use e.g. curl under linux machine to see what happens and what is the difference when you call NC via Domain and via internal IP:

curl -v -k https://yourDomain

and

curl -v -k https://yourInternalIP

• -v is to show more output
• -k to ignore Certificate, this will help in case you ngnix tries to terminate TLS connection.

Example with google:

# curl -v -k https://google.com
* Rebuilt URL to: https://google.com/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 216.58.208.46...
* TCP_NODELAY set
* Connected to google.com (216.58.208.46) 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
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Unknown (8):
{ [15 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3495 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=*.google.com
*  start date: Oct  3 17:09:45 2019 GMT
*  expire date: Dec 26 17:09:45 2019 GMT
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  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
} [5 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* Using Stream ID: 1 (easy handle 0x14897d0)
} [5 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
> GET / HTTP/2
> Host: google.com
> User-Agent: curl/7.58.0
> Accept: */*
> 
{ [5 bytes data]
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
{ [1 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [256 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [256 bytes data]
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
} [5 bytes data]
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
} [1 bytes data]
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
< HTTP/2 301 
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< date: Thu, 24 Oct 2019 08:47:27 GMT
< expires: Sat, 23 Nov 2019 08:47:27 GMT
< cache-control: public, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: quic=":443"; ma=2592000; v="46,43",h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000
< 
{ [5 bytes data]
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
{ [1 bytes data]

100   220  100   220    0     0   1189      0 --:--:-- --:--:-- --:--:--  1202
* Connection #0 to host google.com left intact
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

[autotel]

thanks, @gas85 !

I was just now writing a huge report with all the curl possibilities from the LAN and WAN, because I followed all your recommendations but the problem persisted.

I had a realization. Sometimes I amaze myself with the stuff I can filter out: there has always been another router on my way out to internet. I just added the forwarding of the port 443 on that other router too, and the problem just disappeared. Instead of doing so much work on ssh and the so, I could have just looked at where the routers are placed here at my left .