Issue Accessing Cockpit from Home Network

[fefekrzr]

• Plugged into router.
• Don’t recall specifically, but it’s at least a couple of years old.
• Running Debian GNU/Linux 12 (bookworm) and FreedomBox version 24.14.

Hello everyone,

For the past few months, I’ve been encountering an issue with accessing Cockpit from within my home network. Every time I try to log in, I receive a “Connection failed” error page. I haven’t made any significant changes to my FreedomBox setup that might explain this error. I’m unsure whether this is a FreedomBox issue or specific to Cockpit.

Interestingly, I can still access Cockpit using my external domain. This led me to reflect on any changes I might have made that could have triggered this issue. The only thing I recall doing differently was logging in externally to perform some administrative tasks on my FreedomBox.

Recently, I had to spend some time away from home and needed to access my VPN from a network that blocked UDP traffic. To work around this, I accessed Cockpit remotely and opened a TCP port for the VPN in FreedomBox’s firewall. That’s the only change I made.

I’m not sure if this firewall change or the act of logging in externally could have caused this issue with Cockpit access internally. Both possibilities seem unlikely to me. Has anyone else experienced this? I’m unsure how to reproduce the issue.

I haven’t tried re-running Cockpit’s setup or reinstalling the app. While this might resolve the issue, I wanted to get some feedback or ideas first.

Thanks!

For reference, this is the error page:

[kopfkind]

Hey @fefekrzr.

I remember that there were some issues around firewalld back during the bookworm upgrade. Did you check if you can see anything related to packets being dropped? I’ve seen you being part of the discussion then, so I assume you may have already checked this:

Debian 12 (Bookworm) release and upgrading

Debian 12 (Bookworm), the next stable version of Debian, is planned to be released on 2023-06-10 [1]. FreedomBox can update itself to use the new version of Debian after it is released. To enable this feature, on the System → Update page, ensure that both “Enable auto-update” and “Enable auto-update to next stable release” options are enabled. Note that there must also be 5 GB free space on the system disk, in order for the automatic update to proceed. See the manual page [2] for more details. …

Aside from that, do you know if the issue occurs between browser and fbx or somewhere deeper down? If it’s on the browser side, you could try looking at the developer tools if there’s anything coming up. Alternatively, the standard question: Did you enable and check your logs?

Update / Another thought: Did anything change on the network around your setup, esp. around DNS?

Cheers & HTH,
Axel

[fefekrzr]

Thank you very much for your reply! It’s great having someone to bounce ideas off. I tried the simplest suggestion first, and it seems there’s something about my browsers causing the issue. Generally, I use LibreWolf (a Firefox fork) for FreedomBox-related apps. I just tried opening Cockpit locally with Brave (a Chromium-based browser), and it opens without any issues.

I’ve checked the console messages and network requests from both browsers, and here’s what I found:

LibreWolf

Console messages

index.js:2:641010
Server has closed the connection.

index.js:2:641173
transport closed: disconnected

cockpit.js:1:5119
LibreWolf can’t establish a connection to the server at wss://freedombox.local/_cockpit/cockpit/socket.

Network requests

Unauthorized login response

GET https://freedombox.local/_cockpit/cockpit/login

HTTP/2 401 
content-type: text/html; charset=utf8
x-dns-prefetch-control: off
referrer-policy: no-referrer
x-content-type-options: nosniff
cross-origin-resource-policy: same-origin
x-frame-options: sameorigin
onion-location: http://ni2rn5aq7l2jozctmhj5ylnuguaxl7o6cdrjuseekrv5gfbtyemplvid.onion/_cockpit/cockpit/login
strict-transport-security: max-age=31536000; includeSubDomains
date: Tue, 16 Jul 2024 13:16:27 GMT
server: Apache/2.4.61 (Debian)
X-Firefox-Spdy: h2

Socket

GET wss://freedombox.local/_cockpit/cockpit/socket

NS_ERROR_CONNECTION_REFUSED

Brave

Console messages

updates.js:2
Tracer failed: "{"problem":null,"exit_status":1,"exit_signal":null,"message":"Traceback (most recent call last):\n  File \"<string>\", line 2, in <module>\nModuleNotFoundError: No module named 'tracer'"}", data: """"

Network requests

Socket

Request URL: wss://freedombox.local/_cockpit/cockpit/socket
Request Method: GET
Status Code: 101 Switching Protocols

In summary, it seems that the Firefox-based browser (LibreWolf) is having issues with the authentication process for some reason.

Thanks again for your help!

[kopfkind]

Good to hear that you could narrow it down to the browser! Maybe it’s related to privacy settings in LibreWolf? I use Firefox a lot with “strict” settings and some pages break. In your scenario the authentication in a websocket connection failed - maybe the browser settings prevented sending your session information (cookies, auth token, …) with it? LibreWolf may also disallow self-signed certificates if you are using one (cf. here).

You could try experimenting with settings in LibreWolf to see if you can make it work without compromising your privacy needs.

[Ged296123]

Firefox sometimes creates a similar issue.
Cleaning the cache along with any login/credentials amd history solves my problem. Maybe related?

[joseph]

I just experienced the same issue from the internet side on my freedombox. Cockpit worked, then I had this problem, and then it worked again. This is from a remote location connecting to Cockpit over internet using a DNS host name.