AWS Slave Bridge Issue

[ajnewtexas]

Good morning,
I have several windows based 3CX installations, on the latest that connect to each other via static IP bridges without the an issue. We have a new AWS based bridge that will not connect to our Windows based master. Firewall checks on both are fine. Seeing “Destination (sip:127.0.0.1:5080;lr) is not reachable...” Dns won’t resolve...on the slave. And 127/5080 is not the ip and port I’ve entered in the bridge info. Anyone seen this? Thanks!!

 

[leejor]

3CX is getting that IP from somewhere. Have you tried deleting the bridge and starting over?

 

[ajnewtexas]

I have tried deleting. No clue where 127.0.0.1 is coming from. My static ip is in the bridge info...and not on the port this alert is reporting

 

[leejor]

127.0.0.1 is the localhost, or loopback IP. It's generally shown in the Activity logs if there is no external IP (to the server), being used for a call/routing/registration. Are you using an FQDN or an actual IP? Are you able to ping this?

 

[ajnewtexas]

127.0.0.1 is the localhost, or loopback IP. It's generally shown in the Activity logs if there is no external IP (to the server), being used for a call/routing/registration. Are you using an FQDN or an actual IP? Are you able to ping this?

If tried FQDN and static IP both for the master without luck

 

[conversant]

This a bug and it has been broken since update 4 at least, but 3CX support won't treat as a bug, or do their own testing to verify it. None of our update 4 instances will successfully establish a bridge.

 

[abrown]

I confirm I have the same issue.

Set up a bridge on any of our PBX, and set the tunnel mode enabled on the default 5090 port with either an IP or FQDN for the master PBX.

The error is

Registration at UKMESH Bridge has failed. Destination (sip:127.0.0.1:5080;lr) is not reachable, DNS error resolving FQDN, or service is not available.

Not sure why its trying to connect to a loopback on port 5080. That has not been entered anywhere in any of the PBX's we tested this on.

I'll report the bug as this is a biggy if you need PBX's interconnected!

 

[cobaltit]

99% sure the loopback and 5080 is a result of the tunnel and what you are seeing is a result of 3CX trying to insert the traffic into the tunnel. If you don't use the tunnel to bridge you shouldn't see that anymore.

 

[abrown]

Nope, but then it doesn't work without the tunnel, just gave another error.

Take a full backup.
Shut down the AWS Lightsail.
Deploy the License key on Azure
Restore from backup

retry the tunnel. Works first time.

Spent less than an hour moving the instance, took me longer trying to work out how to actually report a bug to 3CX without having to pay them to buy a support ticket for the pleasure of reporting a bug in their system...

 

[cobaltit]

I'm confused. You said nope, but then you also said it gave another error. So when not selecting the tunnel for bridge use, you still saw an error with destination of 127.0.0.1:5080?

 

[cobaltit]

And I still haven't seen exactly what the 'bug' is. Is it that bridges won't work when AWS is part of the bridge?

 

[abrown]

Cobaltit. Sorry my response was not that clear..

turning off the tunnelling also does not work . However the error is a 405, malformed sip registration error. Not the loop back port 5080 error.
And yes, the bug is that bridges do not work for 3CX when one side of them(not tested both ) is hosted on AWS.

same configuration, as restored from a full backup, on new Azure deployment worked without issue

hope that is bit clearer as to why I also reporting the same repeatable behaviour as the original poster of this thread.

 

[cobaltit]

Perfect, thank you. And both of you are on full AWS? Have you tried Lightsail?

 

[AWS2P]

It seems to be the same problem on lightsail, just tried and got same error



@JohnS_3CX can you confirm us this is something 3CX is on way to fix it?

 

[JohnS_3CX]

I can confirm this works as tested:

1.) on V16.0.4.493
2.) With and without tunnel
3.) Both ways (Slave Google to Master AWS / Slave AWS to Master Google)
4.) Also tested on 2 local PBX machines that are on the same subnet and worked

The 127.0.0.1:5080 is where the tunnel terminates internally. This is how it appears in the logs as this is how the PBX talks to the tunnel, so don't worry about seeing that address-port combo.

• I ensured that both on master and slave the Virtual extension number and password were the same (otherwise authentication fails).
• I ensured that the correct IP of each opposite machine is entered
• I ensured the opposite side IP is not blacklisted on both sides
• I ensured the bridge worked with tunnel enabled and without

I deleted and recreated them on both ends and in both directions 3 times. On some attempts the registration failed the first time, upon pressing "Refresh Registration" it came up immediately. You should be able to at least establish the connection even if the 1st registration didn't go through.

You can try it without the tunnel (provided 5060 is open on the firewall) and see if doesn't work there too, captures on both ends can reveal exactly what happened under no-tunnel testing.

Solution: once everything is set up, select the slave bridge and hit refresh registration. If this still fails then contact support for further investigation as the issue here may be somewhere else.

Note: Bridges are 1 to 1 connections so once a machine registers on the Master, if I want another machine to also connect on the Master, I need to create a 2nd Master bridge. I cannot connect to slaves to the same master Virtual Extension number.

 

[AWS2P]

Hi John,
In my case was not a bridge between 2 cloud PBX but one on premise , one lightsail.
Everything you said to take care about is done, only one link Master/Slave is done so very simple case.

 

[JohnS_3CX]

@aws2p

For your case at least you can try it without the tunnel (provided 5060 is open on the firewalls) and see if doesn't work there too, captures on both ends can reveal exactly what happened.