3CX STUN servers are reporting our FQDN IP address incorrectly

[databim]

Hello All,

in the 3CX network settings, "Static IP" is selected, and the fields related to the STUN server are disabled. Despite this and even though the STUN servers should not be tracking our IP address the system periodically reports our FQDN IP address as 74.248.19.11. As a result, our remote extensions are unable to access the PBX or receive calls. While restarting the 3CX services temporarily resolves the issue and ensures the correct (actual) IP address is reported but the problem recurs after a while. The firewall test completes successfully, showing no issues. Here is what we have tried so far:

• We have updated it to Version 20.0 Update 10 (Build 1785 Release - AI 1.6.91). We experienced the same issue in the previous version as well.
• We migrated the system from a Windows server to a Linux server. (in case it has to do with the operating system)
• We enabled "KEEPALIVEENABLED" in the 3CX parameters and set the interval to 30 seconds.
• We set the UDP timeout on the router to 1800 seconds.
• To test our current internet connection, we moved the server to a different location and used a different IP address; however, the same issue persisted, and the system again reported the IP address as 74.248.19.11.

To whom does the IP address 74.248.19.11 belong? Why are we experiencing this issue? I would appreciate your suggestions.

 

[bitn2]

This can really only happen if you have another system running with the same FQDN.

 

[DimitrisL_3CX]

Hello @databim

As @bitn2 mentioned, this happens when two installations have the same FQDN.
So it is either a previous installation that it is still running. For example the IP provided points to an Azure installation.
Or you have a Failover that it is not set to Passive mode and all services are up and running.

 

[databim]

Thanks for your response, Jan. I considered this possibility as well, but that is definitely not the case. It is installed only on our own server and in one single location.

 

[Alphabetic]

That IP belongs to Microsoft so are you sure you didnt set up a VM or something in the past? Replication?

 

[bitn2]

Thanks for your response, Jan. I considered this possibility as well, but that is definitely not the case. It is installed only on our own server and in one single location.

In that case, you should contact 3CX so they can check whether another instance is running under that IP address.

 

[DimitrisL_3CX]

Please note that we have already checked for any other instance running on the specific IP, but found none.

 

[databim]

Please note that we have already checked for any other instance running on the specific IP, but found none.

Dimitri, where do you think the problem lies in this situation? Is it with our server and settings, or with the 3CX servers?

 

[NikosT_3CX]

@databim from the 3CX side we only receive activations and update the A records accordingly.
What I can see is that this started at 10/06/2026 ( June ).
You may need to check back then who had access to the PBX and what they did, meaning where this was set.

 

[databim]

@databim from the 3CX side we only receive activations and update the A records accordingly.
What I can see is that this started at 10/06/2026 ( June ).
You may need to check back then who had access to the PBX and what they did, meaning where this was set.

Hello Nikas,

I don’t recall the exact date the issue began, but it may have been around the time you mentioned. During that period, our internet infrastructure was upgraded from VDSL to Fiber. Throughout this transition, our static IP address remained the same—it definitely did not change. However, I don’t believe this is related to the change in our internet infrastructure; I tested this using a different internet connection to be certain. Even when using different internet infrastructures with different static IP addresses, we continue to encounter the same problem. Occasionally, the system reports our FQDN IP address as 74.248.19.11; when we restart the services, we are able to use our own static IP again for a while.

About a month ago, I performed a clean reinstallation of the system—I did not restore from any backups. Despite this, the issue persists. Therefore, we cannot attribute this to system settings that might have become misconfigured around 10/06/2026; we are still experiencing the problem even after the fresh installation.

 

[Alphabetic]

At this point dont you want to strike up a conversation with ISP too?

 

[databim]

At this point dont you want to strike up a conversation with ISP too?

This is unnecessary because, as I mentioned in my previous message, we encounter the same issue even when testing with a different ISP. At times, our FQDN is reported as having the IP address 74.248.19.11, and this IP is provided by the 3CX STUN servers. Do you still think the problem might be coming from the ISP?

 

[Alphabetic]

Maybe when you tested on the new network, the A record wasnt updated so kept as what it was previously. Wouldnt be a bad idea to ask them if this IP, no? Also, what is your network topology? have you got any Azure connectors or services? Anything running in 365?

 

[databim]

Dear @Alphabetic, thank you very much for looking into this issue and trying to help. I am being extremely careful to avoid any such confusion; during each test, I ensure that the system is running on only one server at a time—meaning I either shut down or delete the previous instance before setting up a new one. I have also tested this on a server hosted on Azure, but the problem persists.

1. The core issue we need to focus on is this: our system is configured with a static IP. According to 3CX documentation, "if a static IP is assigned, STUN servers are disabled and do not continuously track your IP address." It would be very helpful if someone from 3CX could confirm this—or, if that is not the case, explain how it actually functions.
2. Furthermore, even if the STUN server were to track our IP address, why does it suddenly switch to 74.248.19.11 after having correctly recorded our actual IP address and functioning properly for an entire day? Whose IP address is this? And if restarting the services restores everything to normal—allowing the system to correctly register our actual IP address—why doesn't the STUN mechanism correct itself automatically?
3. Another important detail: even when the DNS/FQDN resolves to 74.248.19.11, I am still able to access the 3CX control panel using our actual IP address (https://ourrealipaddress:5001). So, in reality, our IP address never actually changes, but the 3CX STUN servers somehow manage to pick up the IP address 74.248.19.11 and then can't correct it.