Been loving openfire, coming from ejebberd to openfire was a breath of fresh air. Got everything set up and can login from meebo and other various jabber clients from the outside just fine.
I loaded spark on the openfire server to test out stuff locally. For the life of me I cannot connect to an account from localhost. All credentials are the correct, I have tried the public IP, 127.0.0.1, 192.168.0.20, localhost, etc. I know my username and pass are correct (user@mydomain.com)
I am using the internal database so no funky database stuff should be the culprit. And both openfire and spark are the lastest versions as of today.
Netstat -an shows that the server is bound to 0.0.0.0:5222 so it should be listening for traffic on 127.0.0.1 correct? Is it not possible to log in using spark on the openfire server itself? Is there some magical way to format my username so it will work? (user@localhost, user@publicIP)
It looks like the problem is not just from localhost. I added spark to another machine on my network and it cant connect either. But meebo or other services outside my network will connect fine.
Could it be a DNS issue? I know my DNS is configured properly because stuff is finding me from the outside just fine.
I would imagine that on the internal network I could just use an internal IP for the openfire server and it would connect fine. I dont have any rules governing traffic local to my internal network. Of course I am only allowing ports 5222 and 5269 in, but anything can go out.
Openfire in your LAN, using “example.com” as xmpp.domain and IP 192.168.0.1 You have a local DNS server which resolves “example.com” to 192.168.0.1. So this should work fine also in your LAN.
If you don’'t have a DMZ skip this step.
In your DMZ if you have one install a Connection Manager as a simple proxy. It may use 192.168.200.1 as IP address as I guess that you DMZ uses another network. The CM should be able to connect to 192.168.0.1:52?? (whatever the CM port is). You can drop all internet users by shutting down the CM. As CM’'s do not support s2s connections you may want to move Openfire itself in the DMZ for s2s connections to work.
Configure your firewall / router to map publicIP:5222 to 192.168.0.1:5222 (or 192.168.200.1:5222 if you use CM/DMZ). Ask your DNS provider for a mapping of “example.com” to publicIP. If you use “example.com” also for your web server make sure that your provider is using SRV records.
Thanks for the clarification. Seems as if it functions much the same as any other client/server app. If you wouldnt mind clarifying a couple other issues along this same line.
Wildfire is set up to only manage users from 1 domain correct? This means that the username you use should be just “user” not "user@domain.com" correct? I was using the user@domain.com as my username and I believe this was the problem.
We have an app that uses xmpp gateways and when we try to login with just a username it throws and error saying that username must be specified as "user@domain.com" and it is impossible to submit login info without what they consider to be a “full” username.
How hard would it be for wildfire to listen for incoming usernames and drop everything after the ‘’@’’ symbol when authenticating? That way no matter what method people decide to use they would be able to login without confusion.
Any thoughts for or against?
Finally as far as “xmpp.domain” is concerned. Is this really used for anything? I mean, if I had xmpp.domain set to “blah.blah” could I still point public DNS for “mydomain.com” port 5222 to my internal box and have it authenticate?
I really only see the xmpp.domain being relevant if you are hosting multiple domains on one server and want to split up the user base into separate domains, something that wildfire doesnt support at the moment, correct? Maybe xmpp.domain should be in the user manager?
a JID consists of the username*"@“domain(”/"*resource). If you use “B@man” as username which is possible the client will esacpe the “@”, your username will get “B\40man”. Some client require that you use the JID as username as they don’'t allow to specify a server. The client has usally no AI to handle “@”.
I mean, if I had xmpp.domain set to “blah.blah” could I still point public DNS for “mydomain.com” port 5222 to my internal box and have it authenticate?
If your server allows this and your client can handle this, yes. Welcome some confused users, their JIDs will be “user@blah.blah” and not as expected “user@yourdomain”.