powered by Jive Software

Messenger from behind a DMZ

How can I configure my system so I have Messenger on the local network if I want clients from the internet to access it?

Our network is classically put where we have the internet, a DMZ and a local network. I guess there will have some sort of proxy in the DMZ but what will do the job?

You’'ll need to open up ports 5222 and 5223 so that outside clients can connect to the server.



Thank you Matt but I think I did not made myself clear. Our network is configured this way : Internet|Firewall|DMZ|Firewall|Local network.

We want Jive Messenger to be in our local network and we want to be accessible from the internet. Opening ports will do nothing since our local network is not visible from the internet.

My question is: what can I use in my DMZ to connect our internet clients to our Local Jive messenger server?

There’‘s nothing mystical about Jive Messenger that it needs anything special setup to run in a DMZ environment. If you are using 2 private networks for your DMZ and LAN, just setup your NAT translations on your firewalls and allow the Jabber ports through to the Jabber server. It’‘s not really any different from setting up a webserver. All communications are done between the client and the server. There is no client-to-client communication happening – it’'s all client->server->client.

I understand that no specific proxy is available for Jive messenger and portfowarding is the simplest solution. I don’‘t know if it’'s 100% secure but our security guys will tell me if it is a problem.

I’'m not sure if my last post made any sense. I missed the part were you said you wanted JM to be on your local network. Sorry if it was confusing.

General rule of thumb: any publically accessible services should be housed in your DMZ. I’‘m sure you have reasons for wanting to keep it on your local network, but I’'d recommend that you reconsider. The DMZ is there for a reason (security) and poking holes into your local network is generally a bad idea. If you are needing to tie JM in with a private LDAP server on your local network (such as Active Directory), it would be better to put JM in the DMZ and open a single port (tcp 389) to the LDAP server than to put JM on your local network and forward a public port to it. That way, if you JM server is compromised, it only has one avenue of attack against the LDAP server – port 389. If it were compromised while on your local network on the same segment as your LDAP server, the intruder would have a much larger attack surface to work with.

Hey guys

Just to be 100% sure on this…

How bad would it be if those 2 ports were open and were only used by the jive messenger on the local network?

My networking skills are very low… So I’'m going to take any replies and check them out with our networking team… Basically trying to get different ideas…

( as with uducharme, I’'m essentially working on the same project )

Now if the messenger is based on the local network, we could simply have a prodxy setup so that when the request comes in on the port(s) mentionned above, the proxy would translate that and send it through the firewalls and to the jive messenger server. Is it that easy? or?

If my understanding is correct, if we placed the jive messenger server in the DMZ, then we would more than likely have to use some type of XML-RPC to go through to our local network to connect to the database, determine if the user has access to the system, come back with the results, etc…

Ideally we’'d like to place it all in the local network and possibly use a proxy.

Does this sound feasible? Hell with my limited knowledge in this department, did it even make sense? hehehehehe

Thanks guys for the input

The way we do it is each internet user uses SSH to log into a server on our DMZ and forwards port 5222 to our jabber server. They then set their client to localhost and port 5222. Quite standard way to do this and most of the security folks should agree that is the safe way to do it.

Good luck.


I’'m not sure if this setup would work in our case.

We have the whole firewall DMZ thing, but the clients themselves are essentially like users connecting to MSN or aol… they’'re simply given the client and it auto connects to our address. In your example I believe the people useing the software would simply connect to their localhost and that would then connect them to us. Is this correct?

I’'m assuming in a case like that we could have something like a proxy server in the DMZ which would forward port 5222 to the jabber server?


Since I work for a major insurance company as their senior security engineer, let me add a few free words of advice.

Rule 1: Nothing comes in on the network layer from the Internet to the core without stopping at the DMZ. This stops buffer overflows. I know Messenger is a Java app, but network attacks can hit your machine before they even get to your application. The perfect example is the recent Microsoft IP validation vulnerability. This allowed specially crafted IP packets to either kill or take over the target machine on any port with any IP protocol. Nothing but a proxy can stop that sort of problem. For fun reading check out Microsoft Security Bulletin MS05-009.

Rule 2: If you need to share communcations with remote workers out on the Internet, make sure the communcations are going over SSL. No need to broadcast confidential information out onto the Internet.

Rule 3: If you need to get at resources on your corporate LAN/Intranet/Core (whatever you call it), you need to stop off at the DMZ with an application proxy. In this case you could probably use another Messenger server as a proxy. I don’‘t know how you set inter-Messenger server communications up, but I assume it’‘s possible. XMPP servers loose a lot of value of they can’‘t talk to other XMPP servers. The DMZ Messenger would simply route your XMPP messages into the core XMPP Messenger. Simple. The DMZ Messenger is a “limited hangout”. It’‘s purpose is relay communcations in securely on a good day and to gracefully withstand attack on a bad day. In the worst case the DMZ Messenger should give up a minimum of information and when it does finally loose it, the core Messenger should be able to figure it out and drop communications with it. That way, all you have to do is re-install the DMZ Messenger, shore up your failed security and you’'re back online.

Rule 4: Setup the Messenger proxy to only accept connections via SSL so your comms are secure. Setup the Messenger proxy server to authenticate against an internal LDAP database and secure that via LDAP/SSL so that the authentication traffic can’‘t be sniffed if someone cracks one of your DMZ machines. (I wouldn’‘t do auth against Active Directory because it requires you to open a boatload of ports into your internal network. That would be bad.) I also wouldn’‘t do local authentication on the proxy itself. There is too much chance that userID’'s and passwords could be stolen from the machine. It would also be a pain-in-the-ass to sync the DMZ auth database with the internal one.

There you have it. The clean security solution from someone who does it fulltime.

If you turn on a fixed width (monospace) font, the following ASCII diagram should serve as a rough outline:

— cut here —

(incoming Internet connection) *----

! firewall !----

SSL ----------+ (internal connect)




  •                    !

dmz XMPP ! (proxy messenger)


  •                    !



! V

!LDAP/SSL *----

! core XMPP !


V (internal messenger)


! LDAP serv


– cut here —

BTW: If for some reason you can’'t use Messenger in the DMZ as a proxy for the one in your core network you could always run a plug proxy on the DMZ. Not nearly as clean, but better than nothing. You can download and compile the TIS fwtk plug proxy (called plug-gw) for free. Just search google for ‘‘fwtk’’.

Good Luck,

Jim Burnes