No IPv4, only IPv6

Openfire Openfire Support
1

I stumbled across a mysterious problem, which has been lasting for a week or so. My OpenFire 3.6.4 no longer seems to communicate using IPv4. Upon startup it just says that the IPv4 sockets are already in use (they’re not), and just starts everything on IPv6 (which works fine). So now I only have OpenFire on IPv6:

java 8481 openfire 29u IPv6 88200 0t0 TCP *:7777 (LISTEN)
java 8481 openfire 32u IPv6 88202 0t0 TCP *:5229 (LISTEN)
java 8481 openfire 34u IPv6 88211 0t0 TCP *:xmpp-server (LISTEN)
java 8481 openfire 48u IPv6 89318 0t0 TCP *:9090 (LISTEN)
java 8481 openfire 53u IPv6 89330 0t0 TCP *:9091 (LISTEN)
java 8481 openfire 67u IPv6 89349 0t0 TCP *:xmpp-client (LISTEN)
java 8481 openfire 71u IPv6 89360 0t0 TCP *:5223 (LISTEN)
java 8481 openfire 73u IPv6 93614 0t0 UDP *:60958

Looking at the logs it just says it has no network connectivity to talk to other servers (or users).

This is using 3.6.4 on Debian Testing with these java packages:

ii sun-java6-bin 6-16-1 Sun Java™ Runtime Environment (JRE) 6 (ar
ii sun-java6-jre 6-16-1 Sun Java™ Runtime Environment (JRE) 6 (ar

Any idea of what might be the problem? IPv4 on the machine works fine. And I also tried to reboot the machine in case there was a problem with anything in the kernel or whatever. Been running for years without any such problems.

2

You probably need to tweak /etc/sysctl.d/bindv6only.conf. If you google for ‘bindv6only’ you’ll find a lot of debate about the recent change.

3

java 8481 openfire 29u IPv6 88200 0t0 TCP *:7777 (LISTEN)
java 8481 openfire 32u IPv6 88202 0t0 TCP *:5229 (LISTEN)
java 8481 openfire 34u IPv6 88211 0t0 TCP *:xmpp-server (LISTEN)
java 8481 openfire 48u IPv6 89318 0t0 TCP *:9090 (LISTEN)
java 8481 openfire 53u IPv6 89330 0t0 TCP *:9091 (LISTEN)
java 8481 openfire 67u IPv6 89349 0t0 TCP *:xmpp-client (LISTEN)
java 8481 openfire 71u IPv6 89360 0t0 TCP *:5223 (LISTEN)
java 8481 openfire 73u IPv6 93614 0t0 UDP *:60958

That looks fine, my openfire server looks exactly the same. The JVM can handle IPv4 and IPv6 request from the universal socket listener. At least it works for me. IPv6 stack is preferred by default, but you could add the startup parameter

java ... -Djava.net.preferIPv4Stack=true ...

to prefer IPv4.

4

I found this page while having an entirely different problem. I’m leaving my findings here for posterity, in case someone else stumbles upon this in the same way I did.

Even though netstat was listing only tcp6, my server (CentOS 7) is allowing ipv4 just fine. The problem on this server was that firewalld was active out-of-the-box (netstat only confused me in thinking ipv4 not being available was the cause, while it was not).

I quickly verified by disabling firewalld that this was indeed the cause of my problems. After that, I’ve created a new file /etc/firewalld/services/openfire.xml in which I stored this content:

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>Openfire</short>
  <description>Openfire is a real-time communications server, that relies on the XMPP protocol.</description> 
  <port protocol="tcp" port="4443"/>
  <port protocol="tcp" port="5222"/>
  <port protocol="tcp" port="5223"/>
  <port protocol="tcp" port="5229"/>
  <port protocol="tcp" port="5262"/>
  <port protocol="tcp" port="5263"/>
  <port protocol="tcp" port="5269"/>
  <port protocol="tcp" port="5270"/>
  <port protocol="tcp" port="5275"/>
  <port protocol="tcp" port="5276"/>
  <port protocol="tcp" port="7070"/>
  <port protocol="tcp" port="7443"/>
  <port protocol="tcp" port="7777"/>
  <port protocol="tcp" port="9090"/>
  <port protocol="tcp" port="9091"/>
  <port protocol="udp" port="10000-20000"/>
</service>

Finally, I enabled and saved the service:

$ sudo firewall-cmd --add-service=openfire
$ sudo firewall-cmd --permanent --add-service=openfire
1 Like
5

I should probably know this, but what are the UDP ports for?

6

Those can be used by the Jitsi stack in OFMeet.

1 Like