Private & public VirtualHost listeners

Is it possible to configure Prosody to make it listen on different interfaces for different VirtualHosts?

I ask because I added in my Prosody config a VirtualHost to act as a “regular” XMPP server, in addition to all of the internal VirtualHosts used by Jitsi. Doing so required exposing the c2s port on my firewall (5222), but this exposes the c2s connections of all VirtualHosts on the server, including jitsi.domain.tld. And since it has a DNS entry (matching the one used for Jitsi Meet), XMPP clients can indeed reach it–which I don’t really want.

I was hoping that Prosody’s c2s_interfaces could be set for individual VirtualHosts, so that I could set jitsi.domain.tld to listen only on localhost, while my “regular” XMPP VirtualHost listens on 0.0.0.0. Unfortunately, it looks like that setting configures the interfaces used for all c2s connections, not per VirtualHost. But maybe I’m just misunderstanding something.

Is there any way to configure Prosody listen only on localhost just for Jitsi’s VirtualHosts? Or is this outside the scope of what Prosody can do, and falls more in the realm of firewall / DNS settings?

Don’t think it can be done. From the Prosody doc:

Port and network settings

Because open ports are per-system, these settings affect the whole server and can only be present in the global section of the config file

This said, if you want to separate Jitsi from your regular XMPP server, I don’t think anything will block you to create another Prosody instance on your server. It should just be a matter of copying the prosody systemd service control file. I’d say that by changing it to specify --config= you should be set. Not tested it myself though :slight_smile:
Edit: possibly the starting directory too.
However, I tested for you Jitsi-meet on port 6222. No problem. (I did not try Jibri but it should be a breeze)

1 Like

Thanks, that’s a good idea–and should also help the “regular” Prosody configuration to be resilient to any changes pulled in by the jitsi-meet-prosody package.

Though it looks like there’s a lot involved in how Prosody’s systemd service is set up to pick the right config/data dirs, so I’ll have to do some reading before I make the leap :slight_smile: Thanks again!