SIP trunk doesn't register when WAN backup connection kicks in

[bumbumciccio]

Dear all
I have a 18.0 (Build 312) installation which works fine.
I have setup a backup WAN connection in the firewall (a FortiGate 60F unit).
The primary WAN connection has a public static IP address.
The backup WAN connection is through a 4G router and doesn't have public IP address.
When I simulate primary WAN connection failure, 3CX doesn't register its trunks anymore.
I thought it was an External IP configuration issue, therefore I selected "Dynamic Public IP (IP changes)" and left the default STUN servers, then confirmed with OK.
In the dasbhoard under Information panel, IPv4 reports a red label "Detecting".

The Event log reports

• Registration at CloudItalia has failed. Destination (sip:83.211.227.21;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  SIP Server ID: 12293 08/07/2023 5:07:52 PM
• Registration at CloudItalia has failed. Destination (sip:83.211.227.21:5060;lr) is not reachable, DNS error resolving FQDN, or service is not available.
  SIP Server ID: 12293 08/07/2023 5:07:52 PM
• STUN server stun3.3cx.com:3478 could not be reached (host name is not resolved). It could be that the STUN server you are using is down or a network problem is preventing STUN resolutions. This might cause problems if you use VoIP Providers.
  SIP Server ID: 12295 08/07/2023 5:07:25 PM
• STUN server stun-eu.3cx.com:3478 could not be reached (host name is not resolved). It could be that the STUN server you are using is down or a network problem is preventing STUN resolutions. This might cause problems if you use VoIP Providers.

However, if I open the terminal from the dasbhoard and try to ping SIP trunk address or STUN address they ping fine.

I assumed the Fortigate firewall blocked something, however with a softphone I'm able to connect to the SIP trunk with no problems using the same backup Internet connection.

I also waited for the FQDN to update IP address, it matches the dynamic IP address of the backup connection.

Any suggestions?


With regards,
Nick

 

[TheodorosG_3CX]

This indicates a network configuration issue however, of you try to restart the PBX services does this still occur?

 

[bumbumciccio]

Yes, restarting the problem persists.
I noticed STUN server doesn't work, I tried to change the default one with the VOIP provider one. It still doesn't work. It says "STUN server 147.135.193.83:3478 could not be reached (time out three times). It could be that the STUN server you are using is down or a network problem is preventing STUN resolutions. This might cause problems if you use VoIP Providers."
However if I ping this server from 3CX terminal it pings successfully.

I tried a browser tool to test STUN, it appears to work fine so my firewall is not blocking STUN traffic
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

If in 3CX I specify static IP with the private dynamic IP address of the backup connection of course it doesn't work as it cannot communicate. As soon as I restore primary internet connection and specify its IP address as a static IP address in 3CX, SIP trunks are reconnected.
So either there is a problem with the STUN component in my 3CX installation or some sort of a bug.
How can I diagnose STUN issues in 3CX? Anything specific in the logs?

With regards
Nick

Time	Type	Foundation	Protocol	Address	Port	Priority	URL (if present)	relayProtocol (if present)
0.002	host	596234294	udp	68032057-6b9f-4ada-b991-b7222463e743.local	50255	126 | 30 | 255
0.059	srflx	2606411118	udp	5.90.10.115	46693	100 | 30 | 255	stun:stun.voip.eutelia.it:3478
0.088	srflx	2606411118	udp	5.90.10.115	46695	100 | 30 | 255	stun:stun.l.google.com:19302
0.140	Done

 

[Lee Cramman]

It's not 100% clear form the original post but, given you can't connect to the SIP provider via your backup WAN connection, I assume you are talking about an on-premise PBX, yes? If so a mod needs to move this from the self-hosted to the on-premise forum.

Assuming you are on-premise:

My first thought would be whether Clouditalia is using IP based authentication (i.e. it will only accept incoming connections from a specified IP address). If so you either need to get Clouditalia to switch authentication methods (if possible) or, if they insist you specify IP addresses, you're out of luck unless your 4G provider can offer you a static IP address.

 

[JohnS_3CX]

The backup WAN connection is through a 4G router and doesn't have public IP address.

Sorry, this won't work. Just like your main connection, your backup connection will need port forwarding. No port forwarding = No connection. The problem with the 4G connection is that the NAT happens in the carrier network which you have no control over.

Get a different backup connection (DSL / DOCSIS / Fiber) preferably with a static IP and the ability to port forward.

Better yet, migrate your instance to the cloud so it will no longer matter what backup connection you are using. Your apps will work from anywhere, and your IP phones can connect securely via a 3CX SBC.

 

[Lee Cramman]

Sorry, this won't work. Just like your main connection, your backup connection will need port forwarding. No port forwarding = No connection. The problem with the 4G connection is that the NAT happens in the carrier network which you have no control over.

Get a different backup connection (x DSL / DOCSIS / Fiber) preferably with a static IP and the ability to port forward.

Better yet, migrate your instance to the cloud so it will no longer matter what backup connection you are using. Your apps will work from anywhere, and your IP phones can connect securely via a 3CX SBC.

There are some territories where you can buy 4G with a fixed IP / no NAT but not everywhere and this tends to be a more expensive option. There are also workarounds but they are... messy and expensive... the sort of messy I wouldn't touch when I could have a cheap, secondary x DSL connection.

4G can still work well for sites when the PBX is cloud-based thanks to SBC.

@JohnS_3CX suggestion about using a cloud based PBX does solve an awful lot of problems and it's cost-effective too.

 

[bumbumciccio]

Sorry, this won't work. Just like your main connection, your backup connection will need port forwarding. No port forwarding = No connection. The problem with the 4G connection is that the NAT happens in the carrier network which you have no control over.

Get a different backup connection (DSL / DOCSIS / Fiber) preferably with a static IP and the ability to port forward.

Better yet, migrate your instance to the cloud so it will no longer matter what backup connection you are using. Your apps will work from anywhere, and your IP phones can connect securely via a 3CX SBC.

Thank you for the reply. I assumed it would be a valid setup as long as I selected "Dynamic Public IP" in the External IP Configuration. I will try to obtain a 4G SIM card with a public IP address. This address will be different from primary connection one, so I guess I would still need to select "Dynamic Public IP" when the switch happens.
Does it matter therefore if the 4G public IP address is not static?

With regards
Nick

 

[bumbumciccio]

There are some territories where you can buy 4G with a fixed IP / no NAT but not everywhere and this tends to be a more expensive option. There are also workarounds but they are... messy and expensive... the sort of messy I wouldn't touch when I could have a cheap, secondary x DSL connection.

4G can still work well for sites when the PBX is cloud-based thanks to SBC.

@JohnS_3CX suggestion about using a cloud based PBX does solve an awful lot of problems and it's cost-effective too.

Thank you for the reply. The customer premises are far away from the nearest telephone exchange, so DSL connections were terrible. But I'll check again as maybe it is more cost effective than a 4G SIM card with public IP address.

Sure cloud based would be easier to manage, but when there were some issues when I set up everything on version 15. A lot has changed... But the on-premise installation would ensure less latency and extensions would still work internally when the internet connection is down.

 

[bumbumciccio]

It's not 100% clear form the original post but, given you can't connect to the SIP provider via your backup WAN connection, I assume you are talking about an on-premise PBX, yes? If so a mod needs to move this from the self-hosted to the on-premise forum.

Assuming you are on-premise:

My first thought would be whether Clouditalia is using IP based authentication (i.e. it will only accept incoming connections from a specified IP address). If so you either need to get Clouditalia to switch authentication methods (if possible) or, if they insist you specify IP addresses, you're out of luck unless your 4G provider can offer you a static IP address.

Thank you for the reply. Yes you're right it's on premise and I selected the wrong sub forum.
No, Clouditalia is not using IP based authentication or restrictions, just username and password.
The issue appears to be lack of public IP address therefore no possibility to do port forwarding.

 

[JohnS_3CX]

Hi Nick,

Ultimately you need two things

- a public IP which is unique
- and direct access to it so you can perform port forwarding (no carrier grade NAT)

If you get a 4G service that behaves similarly to a wired internet connection, it should not be a problem. Static IP is of course much better because if the dynamic IPs change too often this will be a problem for your PBX. By the time 3CX catches up and updates its IP address, it might change again which can bring down the trunks, and can prevent remote clients / apps / SBCs from finding the PBX. Keep in mind always that DNS is not real time, and even if your side updates the IP automatically, it doesn't mean that remote entities will also update it fast enough

 

[bumbumciccio]

Hi Nick,

Ultimately you need two things

- a public IP which is unique
- and direct access to it so you can perform port forwarding (no carrier grade NAT)

If you get a 4G service that behaves similarly to a wired internet connection, it should not be a problem. Static IP is of course much better because if the dynamic IPs change too often this will be a problem for your PBX. By the time 3CX catches up and updates its IP address, it might change again which can bring down the trunks, and can prevent remote clients / apps / SBCs from finding the PBX. Keep in mind always that DNS is not real time, and even if your side updates the IP automatically, it doesn't mean that remote entities will also update it fast enough

Hi John, thank you for the clear explanation.
I will try to obtain a secondary connection with public static IP address if it's not too expensive.
In this setup the majority of extensions are connected to IP phones that connect directly to the IP address of the virtual machine 3CX is running, therefore they shouldn't be affected by the obsolete DNS entry, aren't they?

WIth regards
Nick

 

[JohnS_3CX]

Yes the IP phones should be fine