SSL headache: not provided only within LAN. Help!
 

Hello,
I run a nas/webserver with OpenMediaVault. Until the end of February I was living in a different apartment, and my internet provider was X. On the machine I have installed nginx and I have a few websites running there, basically a main domain with subdomains (dns provided by cloudflare). A couple of subdomains don't go through the cloudflare "proxy", but directly to the server, so I have setup Let's Encrypt certs for those two subdomains, everything is working as intended.

On the first of March I moved to a new apartment and my internet provider is still X. I turn on the machine, I try to connect to one of the two subdomains that talk directly to my server and I obtain a nice "SSL_ERROR_RX_RECORD_TOO_LONG". Basically, no certificate is being sent to the browser. Keep in mind that I haven't changed anything on the machine, just switched it off and on again. I thought there was a problem with the certificate maybe, so I re-created it, but still no luck. I decide to have that subdomain go through the cloudflare proxy, and everything is working nicely again.
Another day I give it another try from work, I make the subdomain connect directly to my server again and I re-create the Let's Encrypt certificate. This time, I can see my website! I have no idea what was wrong before, but it's working and I'm fine with this. Except, when I reach home, I get that SSL error again. I have an illumination and I try to connect to my workplace's VPN and access the page again. This time, I can open the website.

So, basically, I can access my subdomain from everywhere in the world except when I'm at home, where the server resides. This is driving me crazy and I don't understand why. I mean, I'm not typing an IP address, I'm typing a domain name, so the request still needs to go through cloudfare's dns servers to be fulfilled (and even if it wasn't, what the heck), and it's not just managed within the lan, is it? Does anybody know what's going on? Also, it worked in the previous apartment!

If I run a traceroute to a subdomain that goes through the cloudflare proxy this is what I get:

If I run the same on the subdomain that is directly connected to the server I just get three * on all hops, I stopped the traceroute after 20 hops. As a final note, if I try to open the non-https version of the page (just plain http) it gets displayed correctly, so I can indeed reach the server also from within my apartment. It's just ssl that it's not working.

Sounds like it could be a "hairpin NAT" issue.

When you connect to your domain from your local LAN, you're connecting to an external IP which is then presumably NATed by the router to the internal/private IP address of you web server, which presumably sits on the same (internal) subnet as the connecting client.

In order for such a setup to work properly, the router has to perform source NAT on packets originating from the local LAN, otherwise the return path will be incorrect (directly from the server to the client, rather than through the NATing router).

I assume you got a new router from your ISP when you moved to your new apartment? Could be your old router handled this scenario properly by default, while your new router doesn't.

Try creating an entry in the hosts file on the client, pointing the hostname to the internal (LAN) IP address rather than the external IP address of the router. If that works, you'll know for sure it's a NAT issue.

The solution would be either to edit the NAT rules in the router or set op a local DNS service on the LAN, directing local clients to the internal server IP rather than the external one. Alternatively, you could redesign your network and put the web server in a separate IP network, forcing all IP traffic through the router regardless of origin.

Thank you for your reply. Indeed, it's a NAT loopback issue, as apparenty my new router does not support it (I managed to find the problem yesterday night, then I went straight to bed, I was going to update this thread in a minute). Editing the hosts file works, it's just weird that http doesn't have this issue, but only https does. This has been confirmed by others, however, so I guess it's just how the thing works. Unfortunately my router has very limited options, and I cannot swap it for another one (I could buy a new one and do double NAT, but I don't want to pat the price :P). For the moment I'll stick to editing the hosts file and I will look into this local DNS thing a bit more in detail, although my router also doesn't allow me to change default DNS servers, so I guess that would be a problem as well. Anyway, thank you for all the useful suggestions, I'll try to come up with something that works!

This strongly suggests the router is transparently proxying (and potentially interfering with and/or spying on) all HTTP traffic.
I'd get rid of that router altogether, if at all possible.

In some cases, an ISP will put their otherwise locked-down router in passthrough/bridge mode if you ask them nicely. You could then put another router behind it, and it would have your public IP directly on its WAN interface.

It's a cable modem, so hardly replaceable (in Sweden there are no laws that force ISPs to accept a different, retail router as in Germany and Italy), as I doubt my ISP will disclose all configuration parameters. Yes, bridging is an option, but to be honest I don't want to spend the money for a new router :P
I'll see what I can do with the ISP, or I will just keep things as they are. I just wished they wouldn't dumb down router firmwares this much...