OpenFire 4.2.3 on Windows Server 2012 R2. Installed successfully except for the “OpenFire requires the following DNS entries” message, made those entries, that message went away.
Installed Spark on the Windows Server 2012 R2 itself where OpenFire is installed and a Windows 7 Pro (x64) machine.
Only the Windows Server Spark client will connect. The Windows 7 machine will not.
Both computers are on the same Windows domain and using the DNS server.
I have been restarting both machines repeatedly, no joy.
I have reloaded the DNS cache on both machines, no joy.
I have spent much time trying to confirm that my DNS settings are correct (and they seem to be), but my question is: why would the server where OpenFire is installed have a working chat client but the other machines won’t? I am no longer getting that OpenFire DNS alert, so does that mean my DNS entries are correct? Does the Spark program on the OpenFire server even touch the DNS settings when it is trying to access the server?
I put in the host name in the Spark connection “Advanced” options and have selected the “Accept all certificates” box on both clients.
The firewalls on both machines are off. Symantec Endpoint Protection is installed.
The Win 7 machine CAN ping the OpenFire Windows server BY the FQDN AND by IP.
The two machines are on the same subnet.
Any thoughts would be appreciated. I have been tearing out my hair on this.
You shouldn’t be putting host in Advanced menu. This setting is just for workarounds when DNS can’t be used. What is your Openfire XMPP domain name (shown on first page of Admin Console) and do you put it into Spark’s domain field on login screen on both server and client PC?
XMPP domain name (from OpenFire server settings): ab . website . com (This is an example. We have our internal-only domain called ab . website . com and our public facing/DNS-registered website is called website . com . Could that be part of the problem?)
Yes, I am putting that ab.website.com name into the Spark client in the “Domain” field on the initial login fields on both the server and the workstation.
OK. I took out the host name of the OpenFire server in the Advanced menu and just clicked the box that says “Automatically discover host and port”. The server Spark connected, the workstation Spark did not connect (this is the same behavior).
Edit: I checked the error logs on the workstation and it says, “The following addresses failed: ‘openfireserver . ab . website . com : 5222 prio:0 w:0’ because java.net.ConnectException: Connection timed out”. I mean, that kind of tells me to look at DNS, but the strange part is why does the Windows server Spark client connect if the DNS settings are screwed up? Both the Windows Server 2012 R2 and the Windows 7 machines are using the same domain controller and the same DNS server (which is the aforementioned domain controller).
Will upload DNS SRV records in a moment.
Also, the Spark connection error on the Windows 7 machine is “Unknown connection error. Please review the logs for more infomation.” and that gives me the above log entry I mentioned.
It looks not like DNS issue. It would say servet is unreachable instead. So it thinks it has found the server and waits for a response and doesn’t receive it. I haven’t tried naming XMPP domain the same as AD domain. It might be the issue, though it works locally, so it is weird. If you are still testing, you can try doing fresh install and giving it some different name, like chat.website.com. Or you can show your SRV entry first. Btw, SRV mostly needed when serving to internet. You can probably live with that error message in Adkin Console and only have alias record pointing to server in your local DNS. Again, haven’t used such setup. Not sure if Spark is not going outside and tries to look for server’s IP on the external DNS, which serves website.
You can try going to Advanced menu again and put server’s IP into host and leave ab.website.com as domain. This way we can rule out network/firewall issues.
I did as you asked for both clients (ie, putting the IP address in the host field, unchecking the box for “Automatically discover host and port”, and leaving the domain name ab . website . com in the domain field). The ports were 5222. Same result: Windows Server 2012 R2 Spark client connected, Windows 7 Spark client did not.
(I didn’t know the XMPP domain could be different from the AD domain; I thought they had to be the same. Thank you for telling me.
This is also the second OpenFire server that we have set up. The first one accidentally had the XMPP domain being the same as the OpenFire FQDN host name (ie, chatserver. ab. website . com was the server name AND the XMPP domain) and that didn’t work, either.)
I just installed the Spark client on a different Windows 7 Pro x64 machine that is on the same subnet (but on a different Windows AD domain). Same behavior: I can ping the IP address of the OpenFire server. I put in the IP address of that OpenFire server manually into the Spark client, with the domain being the XMPP domain, and it won’t connect.
Here’s the exact error message (from the brand new client):
Dec 04, 2018 9:27:20 AM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.SmackException$ConnectionException: The following addresses failed: ‘192.168.8.220:5222’ failed because java.net.ConnectException: Connection timed out: connect
at org.jivesoftware.smack.SmackException$ConnectionException.from(SmackException.java:255)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPConnection.java:612)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection.java:850)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.java:364)
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:1107)
at org.jivesoftware.LoginDialog$LoginPanel.access$900(LoginDialog.java:335)
at org.jivesoftware.LoginDialog$LoginPanel$3.construct(LoginDialog.java:894)
at org.jivesoftware.spark.util.SwingWorker.lambda$new$1(SwingWorker.java:138)
at java.lang.Thread.run(Unknown Source)
Also, the OpenFire Windows Server 2012 R2 machine is a virtual machine running as a guest inside a Hyper-V host.
I looked at the logs for the OpenFire server and I did not see any log entries that mention the failed Spark client logins that I tried today. There are some log failures, but they are from yesterday and don’t appear to relate to any client attempts to login.
Here’s one example error from the OpenFire server from yesterday.
2018.12.03 11:29:24 ERROR [Jetty-QTP-AdminConsole-36]: org.jivesoftware.openfire.net.DNSUtil - Can’t process DNS lookup!
javax.naming.CommunicationException: DNS error [Root exception is java.net.PortUnreachableException: ICMP Port Unreachable]; remaining name ‘_xmpp-client._tcp.ab.website.com.’
at com.sun.jndi.dns.DnsClient.query(Unknown Source)
at com.sun.jndi.dns.Resolver.query(Unknown Source)
at com.sun.jndi.dns.DnsContext.c_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(Unknown Source)
at javax.naming.directory.InitialDirContext.getAttributes(Unknown Source)
at org.jivesoftware.openfire.net.DNSUtil.srvLookup(DNSUtil.java:203)
at org.jivesoftware.openfire.admin.index_jsp._jspService(index_jsp.java:312)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:73)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:49)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:226)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:215)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Unknown Source)
Caused by: java.net.PortUnreachableException: ICMP Port Unreachable
at java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native Method)
at java.net.DualStackPlainDatagramSocketImpl.receive0(Unknown Source)
at java.net.AbstractPlainDatagramSocketImpl.receive(Unknown Source)
at java.net.DatagramSocket.receive(Unknown Source)
at com.sun.jndi.dns.DnsClient.doUdpQuery(Unknown Source)
… 43 more
and then later, after a reboot of that OpenFire Windows server…
2018.12.03 11:45:41 WARN [socket_c2s-thread-3]: org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000003: nio socket, server, /192.168.8.220:49305 => 0.0.0.0/0.0.0.0:5222)
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:487)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:410)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:710)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
at sun.security.ssl.Alerts.getSSLException(Unknown Source)
at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source)
at sun.security.ssl.SSLEngineImpl.fatal(Unknown Source)
at sun.security.ssl.SSLEngineImpl.recvAlert(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.apache.mina.filter.ssl.SslHandler.unwrap(SslHandler.java:728)
at org.apache.mina.filter.ssl.SslHandler.unwrapHandshake(SslHandler.java:666)
at org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:552)
at org.apache.mina.filter.ssl.SslHandler.messageReceived(SslHandler.java:351)
at org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:468)
… 15 more
Edit: I do have Symantec installed on the Win 7 clients, but it has been disabled. I am going to uninstall Symantec and try again. The Windows Server 2012 R2 machine has no antivirus installed and its Windows Firewall is turned off.
Edit 2: I uninstalled Symantec and turned off the Windows Firewall (on the Win 7 client) and that did not do anything. I am going to try to spin up another Windows 2012 R2 server virtual guest and see if that one will work.
I deleted the two DNS records with the XMPP entries. Did not work, same error.
Partial success. I spun up the second Windows Server 2012 R2 virtual guest (on the same Hyper-V) and that worked when using the IP address and the ab . website . com domain. However, this is not a solution because the Windows 7 clients still don’t connect.
That Hyper-V host is using a virtual switch which makes all guests visible to the rest of the network. That virtual switch is currently working, as we are running a production virtual machine that uses that virtual switch.
Also, that new Windows Server 2012 R2 client does not have Symantec installed and is working with the Windows Firewall on OR off.
You can also try leave automatic host detection and just put IP into domain field. You will also need to check in Advanced “Disable certificate hostname verification”. As IP and XMPP domain name won’t match in this case and it should complain about hostname not matching. Although you can try first without that setting to see if it actually going to complain. It seems like some weird connection/network issue. You can also try to disable uninstall Symantec. It should have its own firewall.
It does seem like some weird networking issue. I don’t know why having OpenFire installed on a virtual machine guest would affect how other clients access it on the same subnet and same Windows domain. If you have any ideas on that, please help! I mean, when Spark reaches out to the IP address of the chat server in the initial login process, it’s just a normal TCP request, correct? It shouldn’t be blocked by anything. Regardless, the firewalls on the OpenFire server and the clients are off and neither of them have Symantec installed. The only thing the two successful machines have in common (that is, the OpenFire server which also has Spark working and the other server, which has Spark working) is that they are both virtual machine guests on a Hyper-V host and they use a virtual switch. Other than that, they have the same networking, subnet and Windows AD domain settings as the non-working machines.
I have been using Openfire in Hyper-V environment for many years. First in Linux VM, then in Windows Server 2008 R2 VM (with Hyper-V host being on Windows Server 2012). Sorry, currently i don’t have any other ideas. Maybe that’s something with Hyper-V switch. Yes, it should be a TCP connection. A client connects to 5222 port and then server responds on any port.
Success. It was the antivirus’ firewall on the Hyper-V host that was blocking incoming connections to the Hyper-V guest (where OpenFire was installed). It’s working now after I disabled the firewall on the host. I’ll just have to make some special firewall rules to allow it through. Thanks for your help.
Glad you found the culprit.