Rocket Chat Federation Configuration


I want to have a common channel for both my RC instances. Both are installed on a local server but running on different port.

Instance 1:
Instance 2:

Steps to reproduce:

You must be an Admin.

  1. Options -> Administration
  2. Search Federation and Click
  3. Below is the screenshot of my configuration.

Expected behavior:

The configuration is straightforward and I just follow the instructions, but somehow an error returned, maybe I miss something.

Actual behavior:

Setup return this error.

Server Setup Information:

  • Version of Rocket.Chat Server: 3.3.0
  • Operating System: Linux
  • Deployment Method: docker
  • Number of Running Instances: 2
  • DB Replicaset Oplog: Enabled
  • NodeJS Version: 12.16.1
  • MongoDB Version: 4.0.18

Client Setup Information

  • Desktop App or Browser Version: Browser Version (Google Chrome)
  • Operating System: Windows 10

Additional context

I followed the steps here on the official site:

Relevant logs:

This is the logs in the admin

server.js:204 Federation ➔ dns.error Error: ETIMEDOUT at Timeout._onTimeout (/app/bundle/programs/server/npm/node_modules/meteor/http/node_modules/request/request.js:849:19) at listOnTimeout (internal/timers.js:549:17) at processTimers (internal/timers.js:492:7) { code: ‘ETIMEDOUT’, connect: true }

Federation requires the use of Domains. In other words DNS. It requires SRV records and TXT records added to DNS. Just plugging ip’s in there is not going to work. Its going to try and look up the DNS records for that ip and fail.

Domain is super important. Because this is what the users will type to add a user from another instance. Often used kinda like email. So if your email was: You would want people to be able to easily reach your from their Rocket.Chat server so you would setup: like our docs suggest. Then from their Rocket.Chat instance they could type: and start talking to you.

So in your case, even if you want it private, you’d need to use private dns to pull this off. Even if something like workspace-a.local that your local dns provider could provide the SRV and TXT records up for. Then the other workspace so long as talking to the same dns server could look it up and know how to talk.

The reason DNS plays such an important part in federation is we need to be able to share the public key. This allows Rocket.Chat to fetch the other workspaces public key and then send messages to it encrypted. So messages don’t go clear text over the wire.

1 Like