Issue with Bridges

[fabiomcaldeira]

Hi guys

Reaching out to see if anyone can provide me with some guidance or is experiencing the same issues as me with bridges on V20.

Before we begin...........background about the setup
Currently I am self hosting in our datacentre.
Currently all running on one host.
All VMs have their own Public IPs, Running on their own subnets/VLANs via our Firewall in the datacentre, all required ports are open and SIP ALG is turned off (Firewall checker is green)
All the 3CX Instances are currently working 100% save the bridges, which with our previous hosting provider was working 100%.

Currently I have the bridges setup and they are 50% working.

We have a group of companies, 5 to be exact and previous on V18 we had bridges running
When we did the upgrades we also decided to move them to our datacentre for various reason.

We were unable to get the bridges to even connect if we used the Public IP Addresses, even though I was able to ping the FQDN and IPs and also telnet from the boxes to both IP and FQDN.

So what we ended up doing was allowing internal traffic to flow between the zones.

I can get the bridges to go green and "connect".

When a call is established from the master bridge side both parties can hear the call.
However when a call is established from the slave bridge side the parties from the slave bridge cannot hear anything, however parties on the master bridge can still hear.

When I check the logs it looks like it is trying to connect back to itself (the slave bridge as it tries to connect to 127.0.0.1)

I setup a 3CX server in Azure as a test, built the bridge and it works fine via tunnel, however on the local pbx's that I have installed as VMs they are using direct connection and it is not, is there something that I need to enable? Am I missing something?

Has anyone else had/experiencing this issue or have a resolution for me?

 

[SweetAction]

This is almost for sure a networking issue - specifically a hairpinning issue.

I assume you have a single firewall and that firewall is 1:1 natting the public IPs to each 3CX VM. 1 firewall for all VMs though. It's going to be very dependent on the firewall and how it handles NAT in general, but likely you need some form on NAT enabled that does "NAT reflection" (also known as NAT loopback or hairpin NAT which enables internal network clients to access other internal services using the router's external (public) IP address)

 

[AbdullaR_3CX]

Hello fabiomcaldeira,
of what you mentioned, specially that the slave is trying to connect back to itself, it might be a misconfiguration on the slave side and the media (RTP) stream is being misdirected, most likely because the slave bridge is reporting its IP address incorrectly - either as 127.0.0.1 or not resolving the correct public/internal IP.
Have you checked if the static IP option is configured correctly on your slave PBX ? (Admin Console -> Advanced -> Network)
are you sure that the proper NAT/VLAN settings are selected - (based on your network infrastructure ).

 

[fabiomcaldeira]

Hi SweetAction

Thanks for that yes we tried that didn't work for us, that is why we reverted to the internal zones of those servers being able to talk to one another.
We are currently using a Sophos Firewall.

Normally I would be able to see on the firewalls log viewer where is it being blocked or dropped however there isn't anything there about it at all

 

[fabiomcaldeira]

Hi Abdulla Rabeea 2

I have checked all of that
Currently I am just trying to get the bridge working between 2 pbx and then the rest.
Both have static IPs that have been set and are correct, both have the correct internal IPs set and both can reach each others subnets (Checked both from the firewall policy tester and from the console on Linux, I can ping, telnet and ssh correctly to both boxes to and from each other.

 

[AbdullaR_3CX]

have you tried to activate the option of (PBX delivers audio) so the media will be sent through the PBX and not through the network ? (do it on both the bridges as this forces all media to be routed through the PBX, avoiding any direct RTP path issues)

 

[fabiomcaldeira]

Yes I have tried this as well
Tried it on both the bridges as well as the user accounts that I have created

Currently I still have it enabled but have tried disabling it for testing

 

[AbdullaR_3CX]

Yes I have tried this as well
Tried it on both the bridges as well as the user accounts that I have created

Currently I still have it enabled but have tried disabling it for testing

Did you check that both the bridges are running the latest versions and are they both on the same VLAN ?
have you tried to move the PBX to different VLAN ?
have you checked the logs specifically for any SIP negotiation errors or SDP mismatches ?

 

[fabiomcaldeira]

Did you check that both the bridges are running the latest versions and are they both on the same VLAN ?
have you tried to move the PBX to different VLAN ?
have you checked the logs specifically for any SIP negotiation errors or SDP mismatches ?

Currently they are running again on their own seperate VLANs
I have rules currently setup on the firewall allowing the zones to talk to one another and tested they can reach one another
I have also tested them on the same VLAN and get the same results
Yes we have, the only thing that we can pick up is that the SLAVE Bridge tries to connect to itself (127.0.0.1) and not to the other pbx in question however I am not entirely sure where to change this or if it is normal?

 

[AbdullaR_3CX]

Currently they are running again on their own seperate VLANs
I have rules currently setup on the firewall allowing the zones to talk to one another and tested they can reach one another
I have also tested them on the same VLAN and get the same results
Yes we have, the only thing that we can pick up is that the SLAVE Bridge tries to connect to itself (127.0.0.1) and not to the other pbx in question however I am not entirely sure where to change this or if it is normal?

Okay maybe try to keep both machines on the same VLAN and to establish a direct RTP stream without the option of (PBX delivers audio) on the master and slave, and capture the call flow to investigate if there is any errors, also make sure that the media ports are allowed on your end (the media ports are UDP 9000 - 10999) , also make sure that there is no firewalls/NAT rules blocking or rewriting.

 

[fabiomcaldeira]

Okay maybe try to keep both machines on the same VLAN and to establish a direct RTP stream without the option of (PBX delivers audio) on the master and slave, and capture the call flow to investigate if there is any errors, also make sure that the media ports are allowed on your end (the media ports are UDP 9000 - 10999) , also make sure that there is no firewalls/NAT rules blocking or rewriting.

Good Day AbdullaR

Have tried that run into the same issues unfortunately