channel 3: open failed: connect failed: Connection refused

stststst

Hi, I'm making a new thread as it's a separate issue to the previous thread I posted it in.

I'm trying to set up a new Cryptpad instance. When I go to the URL provided for the access token, I get a The connection was reset error. In SSH using TCP forwarding, I get

channel 3: open failed: connect failed: Connection refused

when I try to connect to the URL with a client.

If I curl:

$ curl http://127.0.0.1:3001/install/#tokenhere
curl: (52) Empty reply from server

The port is on purpose as 3000 is taken on my server, and I have updated httpPort in config.js accordingly.

I have tried both the Docker setup and recommended setup outlined here: https://docs.cryptpad.org/en/admin_guide/installation.html#docker

The same thing happens with both the Docker install and recommended install.

I don't think it's an issue with SSH TCP forwarding because I also tried putting Cryptpad behind nginx and accessing the setup token via domain name and had the same experience.

I'd really appreciate some pointers!

Mathilde

Hello,

Thanks for creating a new thread!

Could you share your config.js file? It would be useful to have your Nginx (or the other reverse proxy you might use) configuration as well. Of course don't hesitate to redact any private information they might contain.

stststst

Mathilde Appreciate the reply.

Btw done some further investigation. I'm pretty sure the issue has nothing to do with SSH incorrectly forwarding the port because I ran curl http://localhost:3001/install/#tokenhere from the server itself (i.e. not from my machine with the port forwarded, or through a VPN, or anything, just on the server directly) and got

curl: (56) Recv failure: Connection reset by peer

so it does appear to be Cryptpad's own node server.

config.js:

module.exports = {
    httpUnsafeOrigin: 'http://127.0.0.1:3001',
    httpPort: 3001,
    adminKeys: [
    ],
    filePath: './datastore/',
    archivePath: './data/archive',
    pinPath: './data/pins',
    taskPath: './data/tasks',
    blockPath: './block',
    blobPath: './blob',
    blobStagingPath: './data/blobstage',
    decreePath: './data/decrees',
    logPath: './data/logs',
    logToStdout: false,
    logLevel: 'info',
    logFeedback: false,
    verbose: false,
    installMethod: 'unspecified',
};

nginx should not be relevant I don't think, as I'm mostly trying to access it without nginx, but accessing behind nginx doesn't change the behaviour. I've also tried modifying my config.js to have httpUnsafeOrigin set to https://cryptpad.domain.tld and httpSafeOrigin set to my sandbox domain, and then putting it behind nginx with:

server {
    server_name cryptpad.domain sandbox.domain;
    
    # speed things up when resuming a session
    ssl_session_cache shared:MozSSL:10m;
    
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

    location / {
        proxy_pass           http://localhost:3001;
        proxy_set_header     X-Real-IP $remote_addr;
        proxy_set_header     Host $host;
        proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 150m;

        proxy_http_version   1.1;
        proxy_set_header     Upgrade $http_upgrade;
        proxy_set_header     Connection upgrade;
    }

    location ^~ /cryptpad_websocket {
        proxy_pass           http://localhost:3003;
        proxy_set_header     X-Real-IP $remote_addr;
        proxy_set_header     Host $host;
        proxy_set_header     X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_http_version   1.1;
        proxy_set_header     Upgrade $http_upgrade;
        proxy_set_header     Connection upgrade;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    http2 on;
}
server {
    if ($host = cryptpad.domain) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    if ($host = sandbox.domain) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    server_name cryptpad.domain sandbox.domain;
    listen 80;
    return 404; # managed by Certbot
}

Edit: Just tried setting log level to silly and verbose to true, and nothing outputted in the logs when I curled the setup token url?

stststst

I've been trying to do more troubleshooting and I'm really stumped honestly. Been testing with docker compose mostly but like I said above, same does happen with the recommended install without docker. There's nothing appearing in /cryptpad/.npm/_logs in the container when I open the install link in my browser.

I tried setting up Cryptpad with docker on my local machine, not my server, and it works fine on here, and I'm doing the same thing. So confused. It could be perhaps an OS issue, but OS shouldn't matter much when it's a docker image. Could be something to do with architecture or something more low-level but I wouldn't have thought that would be applicable for a web app... My server can run other self hostable services just fine, including some crypto-focused services like Vaultwarden, so like, I'm pretty sure it can run modern encryption algorithms just fine. It's a bare metal server not a VPS.

I've also tried moving the other service that was on port 3000 and using Cryptpad's default ports in case the ports were a problem. No change in behaviour though. I really dunno how to debug this.

Edit: Going to append my updates as edits rather than replies so as to not spam with posts.

I've tried ss -l when the docker container is running, and it is showing ports 3000 and 3003 (after I changed back to the default ports) as expected. Idk if it's just showing that because that's how I've exposed the ports with Docker, or if that actually indicates that Cryptpad is listening.

stststst

Update, I think I've fixed it. Basically, I think Node was only serving the server over IPv6 (which my server doesn't have). I realised this by running Cryptpad outside of Docker and running ss -l and noticing that port 3000 is only listening over IPv6.

I then edited config.js's httpAddress. Instead of serving over localhost, I explicitly put the IPv4 localhost address, i.e. 127.0.0.1 for running without docker, and 0.0.0.0 for Docker. Using 127.0.0.1 as the httpAddress gets things working without Docker, but not with Docker. With Docker you need to set it to 0.0.0.0. I've now got it working both with and without Docker (will be using the Docker instance in production).

I hope this can help someone else. It stumped me for ages. And I hope this can help the devs too, because it definitely shouldn't be necessary to specify an IPv4 address in order for it to listen to IPv4?

I'm not sure how to mark a reply as the solution on this forum but if mods are able to do that, that would be appreciated. This genuinely really baffled me for a while.