A VPS server I have went down and I lost connection to my Nextcloud recently. But now that it is back online two of my laptops with EOs versions from 09/22 fail to reconnect while other computers I have with Manjaro and Debian have no problem.
I’ve cleaned the browser caches but they still say problem loading page suggesting proxy or firewall is the source. But this is not the case, so is there an internal DNS cache in the system that prevents reconnection?
The systemd-resolved.service is inactive so I have no idea where the problem is coming from. Even a fresh installation of ungoogled-chromium has the same problem so it is not linked to a specific browser. Any help would be much appreciated.
PS Further note: I just tried using dig and the OpenDNS server to test the URL that’s blocked by my laptop and the answer is a positive response. So Where’s the blockage coming from?
I have my usual DNS servers supplied by DHCP on my router. This is the same on my Manjaro desktop which connects with no problem.
I have used a VPN but am not using it at the moment. Even when I use it, the same problem arises. How do I check the killswitch? Something I’ve never heard of.
It is not enabled by default, if that is what you mean. No problem to use systemd-resolved for DNS instead of NetworkManager, but it requires additional configuration (you need to replace /etc/resolv.conf with a symlink to /run/systemd/resolve/stub-resolv.conf, set up DNS configuration if desired, etc).
What VPN do you use?
Typically a VPN will have a killswitch feature, which prevents the network from being able to function at all except for through the VPN tunnel. The purpose is to prevent inadvertently leaking your IP address if you are disconnected from your VPN. If you reconnected to the VPN and it did not restore your connectivity, most likely your problem is something else.
Is the site serving HTTPS? If not, check that your browser is not redirecting to HTTPS automatically.
Did you try disabling the firewall to test if the issue is related to that?
Thanks for the suggestions and the useful bit of info about systemd-resolved - which I may try if all else fails. But my various test still lead me to the conclusion that there must be some internal system proxy which immediately blocks https connections to by Nextcloud server. If I start up my laptop using a copy of my MX-Linux desktop system on a live USB stick, it connects to my cloud exactly as my desktop does.
As soon as I go back to my EOS system installed on my laptop I have the same problem of SSL error messages. On firefox it shows this:
Error code: SSL_ERROR_RX_RECORD_TOO_LONG
Using other browsers the message is different but they still report a failed connection, presumably the SSL handshake doesn’t work.
Apparently the firefox error message is fairly frequent, though I’ve never encountered it with my Nextcloud server before it went down. Sites giving fixes for it suggest removing the secure DNS proxy that the default setting in the network section shows. I tried inserting an exception rule to my Nextcloud site and then setting it to “no proxy” but this changes nothing. On my MX-Linux system I use a default setting for Firefox so I return to my suspicion that there is something else in EOS that causes the blockage - some kind of black list after a failed connection? But where is it located? The error message is instantaneous when I insert the URL of my Nextcloud, so it can hardly have time to connect to an external proxy.
I begin to despair of ever being able to return to the handy synchronisation feature of Nextcloud to be able to use on my two laptops with EOS that I connect with from different workplaces. Other than setting up my own local Nextcloud which means a lot of hassle, I can’t see a way round my problem.
After uninstalling/reinstalling browsers, openvpn, networkmanager-openvpn and other futile operations, I went back to re-read the DNS page on the Arch Wiki and suddenly saw the light. Before making a DNS search, as on all Linux distros, a browser looks in /etc/hosts for a quick match to IPs.
And of course - stupid me - I suddenly realised that the URL for my Nextcloud connection was pointing to the old IP address, which conflicts with the new one. So obviously any browser would be suspicious!
Removing the conflicting line in /etc/hosts solved the problem immediately. Apologies for having others, especially @BluishHumility try to do the dirty work for me!
