Federation testing fails unless port 8448 is forwarded to 443

[james]

Also, you have to use the base domain in the federation tester not e.g. synapse.cloudron.club.

[DidierMalenfant]

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

@DidierMalenfant Do you have any app installed on the base domain?

@james said in Federation testing fails unless port 8448 is forwarded to 443:

Also, you have to use the base domain in the federation tester not e.g. synapse.cloudron.club.

Yes to both of those (I can curl https://malenfant.net/.well-known/matrix/server too and the returned json looks correct).

It could very well be that the tester doesn't read the well-known server info but if that's the case then, again, maybe that should be added to the docs so others can know they might see this error.

Or maybe I've done something wrong in setting this up...

[andreasdueren]

@DidierMalenfant Potential sources for this Issues that come to my mind:

• DNS propagation
• Cloudflare proxying

But https://federationtester.matrix.org/#malenfant.net correctly recognizes federation. Is this with your fix?

[DidierMalenfant]

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

But https://federationtester.matrix.org/#malenfant.net correctly recognizes federation. Is this with your fix?

Yeah. If I don't forward 8448 then the tester returns the error I put in the original post.

Clouflare proxying is off for both matrix.malenfant.net and malenfant.net in my case.

Does anyone know if the federation tester actually reads the well-known server info as part of the test?

[andreasdueren]

Ok so I was trying to read up a bit on federation because I was confused why federation was working for my domain without port forwarding but not for you and I believe they are actually both working, albeit it may make sense to have clooudron also set up port forwarding of 8448for backup.

If you check federation for your base domain, you can see that it actually checks port 443 not 8448. Federation can work without forwarding port 8448 if the server is configured to use delegation.

While port 8448 is the default for server-to-server federation traffic, an administrator can configure their server to direct this traffic to a different host or port, such as the standard HTTPS port 443. This is what happens when you set the .well-known file in the dashboard.

Here is how it works:

• When another server wants to federate with a domain (e.g., malenfant.net), it first checks for a file at https://malenfant.net/.well-known/matrix/server
• This file contains a JSON object that specifies the actual server and port to connect to for federation
• For a server like matrix.malenfant.net to work on port 443, the file would (and does in your case) contain something like this: { "m.server": "matrix.malenfant.net:443" }
• This instructs all other federating servers to connect to matrix.malenfant.net on port 443, completely bypassing the need for port 8448.

I assume your base domain for user names is malenfant.net not matrix.malenfant.net? So @didier:malenfant.net instead of @didier:matrix.malenfant.net.

So maybe you thought you need to enable federation for matrix.malenfant.net:8448 which is not what would happen, since other servers would check federation for malenfant.net not matrix.malenfant.net

[DidierMalenfant]

Thanks. That was mostly my understanding of how it 'should' work too.

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

If you check federation for your base domain, you can see that it actually checks port 443 not 8448.

This is where the results in my original post surprised me. If you look at the error log I got from the federation tester it looks like is does test for port 8448 and ignores the setting I have in the .well-known file which should point it to port 443.

Once I forward 8448 to 443 the federation testers returns no errors.

So my question was, does the tester ignore the well known file or did I set something up incorrectly when I seup the app? Basically do other people get the same error with the tester when using a fresh install of the app with the .well-known file correctly setup.

[joseph]

@DidierMalenfant Cloudron package does not listen on port 8448. This port is not listed in the manifest - https://git.cloudron.io/packages/synapse-app/-/blob/master/CloudronManifest.json?ref_type=heads . This means that the container won't even have this port opened on the server. Port forwarding in your firewall makes no difference.

I checked your post history, it does seem like you use Cloudron. But just to double check you are using Cloudron to host Synapse correct? Can you check what is listening on your server with sudo lsof -i :8448 ?

[joseph]

@DidierMalenfant ignore my previous post. I understand better now I think you are talking of the federation tester.

You can see https://federationtester.matrix.org/#cloudron.io . It contacts port 443 and not 8443 directly.

The reason for this is:

$ curl -L https://cloudron.io/.well-known/matrix/server
{ "m.server": "matrix.cloudron.io:443" }

Note:

• You have to give the matrix ID domain to the federation tester (i.e cloudron.io) and not your synapse domain (matrix.cloudron.io in our case)
• Also see - https://docs.cloudron.io/packages/synapse/#step-1-select-matrix-ids . You have to do the well-known set up in the matrix ID domain.

[joseph]

Maybe ignore my previous comment too. AFAICT, your domain works fine and does not contact 8443.

[DidierMalenfant]

I think I'm not explaining myself correctly

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Port forwarding in your firewall makes no difference.

It does because I'm forwarding 8448 on my firewall to 443 on the cloudron server. I mentioned that above I think

Maybe ignore my previous comment too. AFAICT, your domain works fine and does not contact 8443.

The well-known part is set up correctly. You can try curl -L https://malenfant.net/.well-known/matrix/server to make sure.

As I mentioned above I am checking malenfant.net with the checker and not matrix.malenfant.net.

The reason my domain currently works with the checker is because I have port 8448 forwarded to 443 on my firewall in front of the server.

If I remove the forwarding and run the checker I get the error I mentioned in my first post:

Connection Errors
Get "https://xx.xx.xx.xx:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Get "https://[xxx:xxx:xxx:xxx:xxx:xxx]:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

which would seem to indicate that the tester does NOT read the well-known file and indeed tries to check 8448.

I just tried right now with the forwarding disabled:

[DidierMalenfant]

Sorry I missed some of your questions above. Yes, I am running synapse on my cloudron server.

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Can you check what is listening on your server with sudo lsof -i :8448 ?

When I run this on the cloudron server (I'm assuming that what you meant) I get no output. That would make sense since the Synapse app doesn't listen on 8448.

My only hypothesis right now is that my setup for the well know file is somehow wrong. The error above also mentions No SRV records found. Is that talking about not finding the well-known info at the root?

[nebulon]

To be honest the port 8448 shouldn't be mentioned anywhere with federation in such a setup. Not sure where this is coming from nor why somehow port forwarding this would change anything. Something we miss here in your setup which makes a difference then. Overall your instance shows no federation setup issues though from the outside.

[DidierMalenfant]

I still think that my well-known file is not being read correctly. So the federation tester reverts back to testing the default federation port, which is 8448 and fails unless I forward it myself to the cloudron's 443 port.

This hypothesis does explain the behavior but what I'm not getting is why the well-known setup on my end would be incorrect. It looks ok as far as I can tell.

[robi]

@DidierMalenfant test with command line tools to see if there are any formatting issues that might be causing this.