Federation testing fails unless port 8448 is forwarded to 443
-
@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...
@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 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?
@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
andmalenfant.net
in my case.Does anyone know if the federation tester actually reads the well-known server info as part of the test?
-
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
8448
for backup.If you check federation for your base domain, you can see that it actually checks port
443
not8448
. Federation can work without forwarding port8448
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 port443
. 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 port443
, 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 port443
, completely bypassing the need for port8448
.
I assume your base domain for user names is
malenfant.net
notmatrix.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 formalenfant.net
notmatrix.malenfant.net
- When another server wants to federate with a domain (e.g., malenfant.net), it first checks for a file at
-
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
8448
for backup.If you check federation for your base domain, you can see that it actually checks port
443
not8448
. Federation can work without forwarding port8448
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 port443
. 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 port443
, 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 port443
, completely bypassing the need for port8448
.
I assume your base domain for user names is
malenfant.net
notmatrix.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 formalenfant.net
notmatrix.malenfant.net
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 port443
.Once I forward
8448
to443
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. - When another server wants to federate with a domain (e.g., malenfant.net), it first checks for a file at
-
@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
? -
@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.
-
Maybe ignore my previous comment too. AFAICT, your domain works fine and does not contact 8443.
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 to443
on the cloudron server. I mentioned that above I thinkMaybe 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 notmatrix.malenfant.net
.The reason my domain currently works with the checker is because I have port
8448
forwarded to443
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 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
?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? -
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.
-
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's443
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.
-
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's443
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.
@DidierMalenfant test with command line tools to see if there are any formatting issues that might be causing this.