I have a lab setup trying to replicate and solve a problem at work. My configuration consists of three OpenFire 4.9 containers using the nasqueron/openfire:latest image running on Ubuntu 24.04.4 LTS.
site1 - xmpp domain name: site1.somedomainname - ip 10.0.0.11
site2 - xmpp domain name: site2.somedomainname - ip 10.0.0.12
I have set dnsutil.dnsOverride on the site1 and site2 servers, pointing the other domain to 10.0.0.10, trying to make them use the hub. Meanwhile on the hub, I have xmpp.gateway.enabled = true and xmpp.gateway.domains = site1.somedomainname,site2.somedomainname (comma separated, no spaces, no typos).
With this configuration, site1 and site2 throw error 404 during S2S connection test. However if I set my domain DNS to use the true IPs of the site servers, connection test succeeds and I can browse MUCs on the opposite site.
internal DNS, all sites set to hub address (10.0.0.10): doesnāt work
internal DNS, each site set to its true IP (10.0.0.10, 10.0.0.11, 10.0.0.12): all worky
changing dnsutil.dnsOverride on spokes and hub node: no change
changing xmpp.gateway.domains value on hub: no change
My current setup (in prod) uses some DNS query resolution policies to force this traffic through a load balancer and Iām trying to insert this XMPP gateway in the middle for data tagging and monitoring reasons. Iām not concerned about the DNS piece necessarily - I am also the DNS administrator for my environment and Iām well versed in the SRV and CNAME records I need to make this work. However this depends on the xmpp.gateway properties working as designed, and right now they are doing nothing. I need the hub to answer for site1 and site2, and I need the sites to use the hub to reach some external partners.
Thanks for your detailed description. For the benefit of others reading along: youāre attempting to make use of Openfire as a Trunk/Gateway, as described in Openfire: Trunking Guide (this is not a very common setup, so I thought Iād call it out).
The nasqueron/openfire image that youāre using is not something that we were involved in creating. Iām wondering if thereās value in ruling out that something in there is causing the issue. Can you, for example, use something else than docker in your lab to simulate the network (maybe you can use three virtual machines, or even three distinct bits of hardware)?
A benefit of not using the nasqueron image is that youād be able to use a more modern version of Openfire. At the time of writing, nasqueronās latest release seems to be 4.9.2 - thatās rather old.
The title of your post is that settings are āignoredā. Iām not sure how you provision the settings. It may be worth verifying in the admin console (page āsystem propertiesā) if the properties that youāve provisioned actually show up in the way you expect them to.
For good measure: youāre aware that the dnsutil.dnsOverride requires you to restart Openfire after any changes? Given that youāre using Docker images, youāre probably doing that, but I thought Iād ask.
To verify if Openfire is using the dnsOverride value, you can bump up the log level. When Openfire resolves an XMPP address using the dnsOverride, it should log (at least in recent versions of Openfire):
Answering lookup for domain ā{}ā from DNS override property. Returning: {}
Hopefully this gets you on the way to figuring out what the root cause of your issue is!
Thanks for your reply and suggestions. I just got back from some travel so Iāll test this out using VMs instead of containers this evening and will check for those messages in the logs. Yes, I restarted the containers after applying the dnsutil.dnsOverride settings on the āspokeā nodes as well as after setting the xmpp.gateway.domains property on the āhubā node.
Iām using the nasqueron/openfire image for my lab because thatās what our production environment is already using. Itās on an air-gapped network so the outdated version isnāt much of a security concern, but the XMPP gateway and DNS override features are a priority. Thanks!
I deployed three new Ubuntu VMs with Openfire 5.0.4 installed and set the āxmpp.gateway.domainsā property on the trunk server with the other two XMPP domain names (comma separated, no spaces). Also set the ādnsutil.dnsOverrideā property on the two spoke site servers pointing to the trunk serverās IP:5269. I now see the DNS override in the logs as you mentioned (I didnāt see this before, but I donāt know if thatās because I didnāt have trace logging on?). It looks like my problem now is certificate authentication failure due to the SASL EXTERNAL problem mentioned in the trunking guide. Iāll issue new certs from my CA to get around this but for now the DNS override and trunking problem is resolved. Iāll try again with the containers another time and see if I can find the difference.
Ah, thatās encouraging. In the mean time, weāre working on some improvements that should make configuring all this a bit easier. In the future, youāll be able to configure the property through an admin console page and make more extensive use of wildcards.
