OPENRESO | Intermittent SBC sites losing proxy address – need detailed explanation of proxy addressing logic

[jordi steiner]

Category / Tag: SBC / 3CX SBC

Hi,

I’m looking for help and technical insight about an intermittent issue with phones behind 3CX SBC, where the phones suddenly lose registration because their proxy address changes by itself.

I manage several customer sites using 3CX with phones behind 3CX SBC (including router phones from Fanvil and Yealink). I would like to better understand how the proxy address on a phone registered via SBC is determined and updated by 3CX, and what could cause it to change unexpectedly.

Environment (same pattern on 3 independent sites):

• 3CX servers are hosted in the cloud (each customer has its own 3CX cloud instance).
• Each customer site connects to its 3CX instance over the public Internet.
• On the customer sites we use Sophos firewalls.
• In the cloud we have FortiGate firewalls in front of the 3CX servers.
• Phones behind SBC are Fanvil (2 sites) and Yealink (1 site).
• Each site experienced the issue at different times (not simultaneous).
• I can request and provide exact firmware versions (3CX, SBC, Sophos, FortiGate, phones) if needed, but I don’t have all of them available right now.

Symptom (2–3 times per year per affected customer):

• Phones behind SBC work fine for weeks or months.
• At some random time, all phones behind a given SBC lose registration at the same time.
• The root cause seems to be the SBC phone losing its proxy and changing its proxy IP, which should normally be its own SBC IP address.
• When I check the phones’ SIP account, the “Proxy” / “Outbound Proxy” field no longer contains the SBC IP address that was there originally.
• The proxy value has changed to another IP address or to an unexpected value, even though no intentional changes were made on the PBX, SBC, firewall or DHCP.
• A simple reboot is not enough: I have to factory reset and fully reprovision the phones (sometimes with difficulty) to get them back in service.
• I also tried leaving the phones completely disconnected (powered off / unplugged) for more than 20 minutes in case of a basic blacklist / security timeout, but this did not resolve the issue – only full factory reset + reprovision works.

In at least one case, the SBC itself still showed as “online” in the 3CX Management Console, but the phones were not registering because they had this wrong proxy value. From what I can see, the problem comes from the SBC phone that “drops” and changes its proxy IP, which is supposed to stay set to its own SBC IP.

My questions:

1. What is the exact logic 3CX uses to populate the “Proxy” / “Outbound Proxy” field in a phone that is provisioned via 3CX SBC (or via router phone mode)?
   • Does 3CX always push the current SBC LAN IP as proxy, or can it use another interface / IP discovered from the SBC?
   • In which situations can this proxy/IP be changed automatically (SBC IP change, FQDN change, backup/restore, template change, SBC reconnecting with a different NIC or IP, etc.)?
2. With hosted 3CX + site SBC (Sophos on-site, FortiGate in front of 3CX), what exactly can trigger a reprovision or re‑push of the proxy field to the phones?
   • Is there any correlation with the SBC reconnecting or being seen with a different public or local IP by the PBX?
   • Could short connectivity drops or NAT changes on Sophos / FortiGate cause 3CX to “re-learn” a different IP for the SBC and push that as proxy to the phones?
3. Are there any known issues or recent changes in 3CX / SBC versions that affect how the SBC local IP or outbound proxy IP is determined and sent to Fanvil / Yealink phones?
   • For example: phones receiving the SBC external NIC IP instead of the LAN IP, phones receiving the wrong local subnet, or phones switching to another SBC/router phone on the same site.
4. Is there any recommended way to make the proxy address more deterministic or “sticky” for phones behind SBC (Fanvil and Yealink) so that they do not silently change proxy, forcing a factory reset and full reprovision?

At this stage I mainly need help understanding the internal logic and possible causes. If someone has seen a similar behavior or has ideas / experiences to share, I’d really appreciate your feedback and suggestions.

If required, I can later collect and provide:

• Exact 3CX versions and build numbers.
• SBC versions and OS.
• Phone models and firmware (2 × Fanvil, 1 × Yealink).
• Sophos and FortiGate firmware versions.
• Logs and pcaps from affected sites.

Thanks in advance for any ideas, explanations or troubleshooting directions you can offer.

 

[jordi steiner]

you have to consider that at all your sites, the set up is the same.

Im very suspicious that its the network device(s).

Was this a problem when 3CX was first installed?

If no - what has changed?

Have you checked the Sophos logs for any ALG? or any form of log off it?

Can you create a rule to allow all traffic to/from 3CX/SBC?

To confirm the problem occurs after the phone pulls its provisioning can you remove the server URL from the autoprovision field from one site to see if the problem disappears?

you have to consider that at all your sites, the set up is the same.
Actually, my feeling is that this week it started to “spread”: on Monday 2 customers were affected, on Tuesday 4 customers, and today I stopped counting. Most PBXs are hosted in our cloud (SEWAN) behind FortiGate 7.3, except 1 customer who is on‑premise without any firewall in front of the PBX. On the customer side, almost all sites are behind Stormshield firewalls and 1 Sophos, except 2 sites (the on‑premise one and another site) which have no firewall at all between phones and WAN. All of them use FQDN provisioning. Only on one site did we have to go as far as several factory resets and manual reprovisioning of the SBC phone.

Im very suspicious that its the network device(s).
I’m suspicious too. I don’t have deep control over all of these network devices; at best, I have admin access on the FortiGates, but not full access to every CPE/firewall the operator manages.

Was this a problem when 3CX was first installed?
No, this did not occur right after the initial installations. For now it’s an intermittent issue, up to 3–4 times a year on some sites.

If no - what has changed?
From my point of view, nothing major has changed on our side. Unfortunately, I don’t have a detailed view of every customer’s internal infrastructure, nor of all security updates pushed on the FortiGates. I’m currently looking for information in the operator’s release / change notes, and I’m waiting for clearer answers from them.

Have you checked the Sophos logs for any ALG? or any form of log off it?
Can you create a rule to allow all traffic to/from 3CX/SBC?
I’ve briefly reviewed logs on two sites together with a customer admin, and from what he showed me everything “looked” fine. He mentioned a semi‑automatic reverse NAT/forwarding option on Stormshield: when traffic is allowed in one direction on port X→X’, if there is return traffic on this port it is automatically allowed. I’m still investigating whether this behaviour could be part of the problem, because I don’t know Stormshield in enough detail. Before asking them to change anything, I need to prepare a clear test protocol and very precise requests for them. That’s basically the reason for my current ‘crusade’ here.

To confirm the problem occurs after the phone pulls its provisioning can you remove the server URL from the autoprovision field from one site to see if the problem disappears?
That’s a good idea. I’ll add this to my test plan and try it on at least one affected site when I can coordinate with the customer, so we can confirm whether the proxy change still happens without automatic provisioning.

In any case, thank you all for your replies, they really help me move forward. I’ll of course keep you updated on any progress. I just hope things calm down tomorrow
although if they do, I might end up becoming a believer.