powered by Jive Software

How to configure openfire to LAN or WAN

I have installed a windows server 2008, tendo a domain, and you put it in the program achieves sparks, but I only work locally, as I do for another is to connect to the same chat

I need to connect the local network chat and internet network

thanks

You will need to open tcp/5222 on your firewall (and perhaps configure a NAT rule for it) and probably update some DNS records. If you don’t know how to do this, ask the person who supports your network.

port 5222 is only required to be open on the end that is hosting the WAN chat server. All outbound connections are by default on most firewalls/routers are allowed.

Diego, who is trying to connect to what WAN server? Is this the same server you have hosted locally (and are able to connect to over LAN) or is it some other server hosted someplace other than where you are (not on your LAN).

If you are attempting to connect to a server somewhere else, that server administrator will need to open port 5222 on their end to allow your connection through. If someone else is trying to connect to your server (hosted on your LAN) then your server administrator will need to open port 5222.

David is right in that it sounds like a port issue. You just need to figure out which side of the connection needs the port opened.

It will require more than opening port 5222 and nat rules. You need to install Openfire and set it up with a Fully Qualified Domain Name such as chat.yourexternaldomain.com. This becomes the XMPP server name which clients will use to connect. Now add DNS entries to the internal and external DNS servers for that name. Then open port 5222 and/or setup NAT rules. Using anything other than a real externally resolvable name for the XMPP server will result in possible issues connecting.

tt

one can use a DynDNS name to resolve to one’s public IP address and have all port 5222 traffic NAT’d to the OpenFire server… this wouldn’t require him having to purchase a FQDN.

you miss the point. the point is the xmpp name of the server must be resolvble externally as well as internally. it should be the same name to ensure consistant functionallity.

Im not too sure it “must” be the same. My current environemnt at home has a DynDNS (actually ChangeIP.com, I like them better) forwarder to my public ip address, and this is what people over WAN connect to my server with. One could also lookup my external IP address and point Spark at that and it will work. On my local network I connect to the server by IP address. The Openfire installation is configured with the name chat.vanomaly.local (not an externally resolvable address) and the server itself (centOS) is configured with hostname dev01.vanomaly.local.

I have a Proxy in front of my servers but behind my routers, so essentially things are getting double NAT’d to get port 5222 traffic through my router, passed to my Proxy box, which then forwards to my dev01 machine for connections.

So basically all 4 ways work to connect to the same server with no issues, it’s all about ports.

Now if someone is trying to run multiple servers on port 5222 at the same time, then the FQDN will come into play since you will have to inspect the request and forward to the appropriate server determined by FQDN. But this isn’t needed for a simple installation…

Thanks for your answers, but still has not managed to connect with other machines. already opened port 5222 and still will not let me connect … here are some pictures of some data from my openfire

http://casper.uphero.com/publica/Dibujo3.jpg
http://casper.uphero.com/publica/Dibujo4.jpg

Users can access the server via ip name prueba.sytes.net not know if this has anything to do with

whats the yellow sign next to your server ip addres second image? looks like soemthing off perhaps?

just to recap: your users can connect to openfire from within your LAN. Your users cannot connect to openfire from over WAN. Correct?

And I can see its a windows server… so have you made sure to open port 5222 on the server itself in addition to making sure port 5222 is forwarded properly on your router/firewall ?

Also, what is that XAMPP app I see running? Is it causing a conflict? (just wondering, never seen it before).

If you can connect over LAN then your openfire should be setup with everything you need. This would mean you can focus on data getting to the server from WAN… See if you can telnet the windows server from over WAN on port 5222 – it should connect if it’s getting through…

I get the yellow symbol from rename it before and not had localhost yellow mark that sign.

Users can not connect, but the sparks that is installed on the server can be connected, but someone who is in another machine can not.

I’ve port open on the router, I doubt if there is then necessary to open the port on the server where it is

The version of XAMPP is the 3.1.0.3 is the latest and most apparently functions as the application should work.

Again, I can only connect from any other machine the machine can connect either LAN or WAN

Ok Ok, I see what is wrong (I think) and apologize to sixthring - he was correct.

The client (spark) may not care what it’s pointed to (ip address, domain name, or FQDN), however in your openfire config, it has to be set to a FQDN.

So, change the “Nombre del Servidor” to a valid FQDN. If you do not have one available, using a DynDNS or ChangeIP.com forwarder URL should be sufficient. I believe this is why you have the yellow sign next to the server name since it cannot be an IP address in the config.

Try it and we’ll see what happens.

Your reply only strengthens my statement. you must do what I said unless you want to use different server names inside the network or out. Most users would not want to be changing this all the time and if it is a company it would be unlikely you would want to. My way is the only way to ensure it works everytime with no changes to spark or any other chat client. Given the fact that he is runn server 2008 I assume this is for business purposes.

Hello sixthring,

I respect your knowledge and opinion.

I think me and you are having a disconnect on what we are discussing. You are 100% correct that openfire itself must be configured with a FQDN in the settings. This is the issue Diego is having, his Openfire install was configured as his IP address or as localhost (per his screenshots), neither of which will work. He must change this to some FQDN, whether that be a domain name he or his company purchases, a subdomain of an existing domain name, or uses a DynDNS (or ChangeIP.com) forwarder URL as his FQDN.

(the DynDNS/ChangeIP.com forwarder URL’s are free and the url itself does not change ever - you set it up and download a client program that updates your public IP address to the forwarder, and whenever traffic hits that URL, its forwarded to the machine its setup to (his server in this case… ports still need to be opened).

It is in my experience, Spark, the client side, doesn’t care what you point it at, an IP address, a non FQDN, or a FQDN, it will connect so long as it can get its port 5222 traffic to the server. But it appears the server isn’t as easily appeased and must have a valid FQDN in the settings before it works properly.

thanks for the answers were very helpful, after doing all that mentioned, only falataba open port or disable the firewall on my server and it was resolved with the local and remote entry sparks

Hello Diego,

Glad you got it working! Openfire/Spark are amazing software!

Just to clarify, it was a port issue that resolved your problem? It sounds like you were missing an open port or had to disable the firewall on your server? Can you confirm the resolution for others, Thanks!

Also,

From your screenshots it appears you are running Openfire from the control console. This will work fine, but won’t autostart on a windows reboot (unless you setup custom batch files, etc).

I’d recommend setting OpenFire up as a windows service, so it will start automatically if you have to reboot yourserver.

http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/install- guide.html

Scroll down to the “Windows Service” section.

Cheers!