powered by Jive Software

Make Openfire accessible over the internet

My situation - Openfire 3.5.2 / MySQL / Active Directory running happily for a year on our LAN, XMPP domain is internal only. I now need to make the server accessible from the “outside”, so my understanding is that I need to do the following -

  1. Move the server to an externally accessible area of the network (DMZ), open required ports inside and outside

  2. Change the XMPP domain to something externally accessible

  3. Update all references to the old XMPP database in MySQL

Now I have tried this previously and come unstuck spectacularly, so I’m now building a new server with the new XMPP domain details. However that still leaves me with the headache of step 3 - I’m not a database person at all so I’m concerned about this step particularly. At least all my users in Active Directory though!

My question is - is there an easier way to do this? Has anyone ever implemented some sort of gateway server / service on their DMZ that would intercept XMPP traffic on a certain address, replace the XMPP domain name and forward to the existing host on the LAN? Likewise the other way round.

If the answer is no (which I’m expecting!) has anyone had any real world experience of carrying out the former process? Any hints and tips?

Cheers, Nick

is there data you need to keep stored in the database?

You do not need to put the server on the DMZ. You need only pass the data via port forwarding. by placing it on the DMZ you expose the server to attacks.

The company’s policy re: public facing hosts is that they must be in the DMZ. I have asked for port forwarding in the past and been refused - I have asked again however as I agree that would be MUCH easier.

Re: data stored in the database - is it not correct that people’s personal rosters (as in non shared groups) are kept in the DB, along with avatars and other such information? If so I wouldn’t want to lose any of that particularly! We are not doing message content archiving which helps…


yes that stuff is in the database. it is a very involved process to change the xmpp.domain in the db.

It’s a shame that you can’t just do the port forwarding. About two weeks after I implemented our openfire server (internal only), I got a request to make it available from the outside so traveling vp’s could connect without the vpn.

Piece of cake.

Opened up the port on the firewall. Created a public DNS name (same as the internal) and that was it. So if traveling users are in the office or outside or on VPN it doesn’t matter. The client always connects with the same DNS name.

Hmm I’m wondering about this now - I guess this is a DNS question really but this is my situation. The XMPP domain is “server.region.internaldomain.com”. “region.internaldomain.com” is the same as our Active Directory domain (one of about a dozen domains in the “internaldomain” forest. and is internal only. “internaldomain” is already registered on the internet to our company, so that’s good.

However, is it going to work having “server.region.internaldomain.com” with a public IP? To do this will I not have to setup a public domain record for the “region” level, in which case surely we will have some nasty DNS lookup conflicts…? Alternatively is it possible to have “server.region” as the A record, even though that would contain a dot?

As I said, a DNS question really. :wink: But as Todd points out, changing the XMPP domain in the Openfire DB (MySQL actually) is probably not a fun thing to do - and if I can get around it just by doing some DNS, that would be great.


This is exactly what we did. Our internal domain is ad.domain.com, our external domain is domain.com. The server is chatserver.ad.domain.com. So to make it work I added the a record chatserver.ad.domain.com on the external DNS pointing at the external IP. That IP forward all openfire ports to your internal IP for the server. Make sure it is bidirectional.