Server to Server

I’m sure this HASN’T been asked many times before (sarcasm). I’ve got an OpenFire server running on my personal server that sits in my apartment. For awhile now, I’ve been trying to enable server-to-server communication with public servers. Haven’t had any success yet. I can connect to my server over the Internet, but it’s impossible for other servers to actually see it for some reason. I should at least get some kind of invalid certificate error (using a self-signed one), or an indication of a server-to-server connection in the logs.

I eventually narrowed the problem down to DNS SRV records needing to be created. So, I created them. They have since propagated through DNS, and I’m able to find them using nslookup. External servers still return a server not found error. So, the things I’ve tried and verified:

  • Server-to-server is enabled in Openfire, and the security is set to optional.

  • Port 5269 is open on my firewall.

  • SRV records are in DNS.

  • Server is using a self-signed certificate.

  • xmpp.domain property is set to polaris.thermetics.net (although the server’s actual hostname on the LAN is different)

I would at least expect something in the logs that shows a remote server connecting and then rejecting the certificate. But alas, that never even happens. Debug log is enabled, and the only thing that shows up are info messages from the AIM transport that’s running (along with the usual stuff from the local server).

Is there something I am missing? Maybe I created the SRV records wrong? nslookup output shows the following:

_jabber._tcp.polaris.thermetics.net service = 20 0 5269 68.49.168.233.

_xmpp-client._tcp.polaris.thermetics.net service = 20 0 5222 68.49.168.233.

_xmpp-server._tcp.polaris.thermetics.net service = 20 0 5269 68.49.168.233.

Thanks in advance for the help.

Still wondering if anyone has any thoughts on this. Haven’t made any progress.

Have you tried installing a certificate see http://xmpp.net/

Its seems that all public services use certs. Check at http://xmpp.org/services/

If other servers cannot connect to your server, it’s their logs that probably include a hint of what’s going on. Have you got access to those?

My guess is that either one server doesn’t accept self-signed certificates, or fails to validate the certificate chain for some reason. If both servers are Openfire based, try playing with these settings to see if you can make the connection succeed:

  • xmpp.server.certificate.accept-selfsigned (default value “false”)
  • xmpp.server.certificate.verify (default value “true”)
  • xmpp.server.certificate.verify.chain (default value “true”)

I hope this helps!

I’ve been running some tests, trying to connect to your server (initially, my router failed to properly forward a port, explaining all of the failed attempts you’ll find in your log).

I have found that I can connect perfectly fine to your XMPP domain, if I configure this Openfire System Property to be “true”: xmpp.server.certificate.accept-selfsigned

This is hardly surprising, given that you use a self-signed certificate. One could argue that allowing self-signed certificates to set-up server-to-server connections should be somewhat more visible in the admin panel. Disallowing them by default might also be somewhat harsh (although, arguably, more safe).

Try setting that system property in the server that initiates the S2S connection to your server, and see if your problems are gone. Alternatively, arrange for a non-self-signed certificate.

Let me know if this helps!

If other servers cannot connect to your server, it’s their logs that probably include a hint of what’s going on. Have you got access to those?

My guess is that either one server doesn’t accept self-signed certificates, or fails to validate the certificate chain for some reason. If both servers are Openfire based, try playing with these settings to see if you can make the connection succeed:

  • xmpp.server.certificate.accept-selfsigned (default value “false”)

  • xmpp.server.certificate.verify (default value “true”)

  • xmpp.server.certificate.verify.chain (default value “true”)

I hope this helps!

I am (attempting to) federate with/enable service discovery from a public server (Google Talk in particular). My original grand master plan with this was to set up my own IM server to enable various transports that I could use to import contacts from other IM networks into my Google Talk buddy list so I can use the default GTalk client on Android when I’m mobile. The logging of everything to Google’s cloud is also another nice benefit.

I’ve been running some tests, trying to connect to your server (initially, my router failed to properly forward a port, explaining all of the failed attempts you’ll find in your log).

I have found that I can connect perfectly fine to your XMPP domain, if I configure this Openfire System Property to be “true”: xmpp.server.certificate.accept-selfsigned

This is hardly surprising, given that you use a self-signed certificate. One could argue that allowing self-signed certificates to set-up server-to-server connections should be somewhat more visible in the admin panel. Disallowing them by default might also be somewhat harsh (although, arguably, more safe).

Try setting that system property in the server that initiates the S2S connection to your server, and see if your problems are gone. Alternatively, arrange for a non-self-signed certificate.

Let me know if this helps!

I do see your successful server-to-server connection attempts under the warn log as:

2010.07.11 03:43:37 Accepting self-signed certificate of remote server: [*.guusdk.mine.nu]

Were you able to successfully connect to service discovery? If so, excellent. I expected that I would eventually have to get an authorized cert in order to federate/service discovery with Google Talk, but I expected at least a connection attempt of some kind to show up in my logs when I attempted to get to my services under service discovery from GTalk.

The next step I will take is to set up another Openfire server running on another host on my network and see if I can verify the self-signed property fix. My guess is that will do it, though in the end I will need an authorized cert to get it working with the public servers. Also, my own xmpp.server.certificate.accept-selfsigned property is already set to true. Thank you for your help thus far.

I didn’t do service discovery, but I did succesfully query your software version (jabber:iq:version). In any case, the connection was set-up successfully.

I do advise you to test out your setup without involving Google Talk - that network tends to be a bit odd in things. Two Openfire instances (as you suggested) should do the trick.

Good luck!