Phone system diagram

[dkha126]

Hello,

We're going to replace our current phone system with 3CX. We've contacted our partner and they suggested using SBC even though we're going to install 3CX on-premise.
The diagram is attached. We have two dedicated lines with public IPs for our phone system.

Based on the diagram, we need 4 servers in total to provide HA. Regarding the SBC servers, as they said, we can utilize our Cisco Voice Gateways or install the virtualized servers.
I'd like to know if this is the best practice in terms of HA and security. Is one 3CX license (Enterprise) enough?

Thanks.

 

[Evolute IT]

This is wrong on many levels.

1. If you install on-premise, you don't need SBCs nor the "CloudPBX" as the PBX is local. The Cisco Voice Gateways are not the same as the 3CX SBC. It could work, but once again, not needed at all.

2. The two servers on-premise would be your "HA", no need for anything else. You can use Split DNS internally to have them change IP when failover occurs.

This doesn't need to be so complex. And yes, one license will be enough (Enterprise tho, that's important.)

Not sure who's the partner you used but it sounds like they just wanna sell you more T&M to set it up.

 

[dkha126]

Hi,

Thanks for your advice. Just a correction about the CloudPBX, it is our SIP trunk provider.
In short, we only need two 3CX servers (one Active, one Passive). Is it correct?
Since each 3CX server will have two interfaces (one is LAN, another one is a public interface), is there any issue with the security? Does the anti-hacking feature on 3CX good enough?

 

[Evolute IT]

In short, we only need two 3CX servers (one Active, one Passive). Is it correct?

Yes.

Since each 3CX server will have two interfaces (one is LAN, another one is a public interface), is there any issue with the security? Does the anti-hacking feature on 3CX good enough?

Security in 3CX is very good and you can adjust it to be stronger as well. That being said, I would recommend you use a firewall in front and only open the required ports by 3CX. If you don't plan to have remote STUN phones, you can even lockdown the 5060 to your SIP provider's IP addresses and improve security that way.

Since you will be using multiple interfaces, I recommend you take a look at https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/ to know how 3CX expects the interfaces to be configured in your scenario.

 

[dkha126]

Yes.

Security in 3CX is very good and you can adjust it to be stronger as well. That being said, I would recommend you use a firewall in front and only open the required ports by 3CX. If you don't plan to have remote STUN phones, you can even lockdown the 5060 to your SIP provider's IP addresses and improve security that way.

Since you will be using multiple interfaces, I recommend you take a look at https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/ to know how 3CX expects the interfaces to be configured in your scenario.

Thanks again.

We're using the Palo Alto firewall and during the pilot phase, we could not make it work although we tried to use 1:1 NAT. Do you have specific instructions in order to use 3CX with Palo Alto?
We have two MPLS lines just for SIP Trunk, so we'd like to utilize those lines. This is for redundancy as well.
One last question, can we allow specific phones (extensions) to be able to send a broadcast message (paging) using 3CX?

 

[SweetAction]

Thanks again.

We're using the Palo Alto firewall and during the pilot phase, we could not make it work although we tried to use 1:1 NAT. Do you have specific instructions in order to use 3CX with Palo Alto?

What's the exact issue you are running into? I've not run into issues with 1:1 NAT with PA.

 

[dkha126]

What's the exact issue you are running into? I've not run into issues with 1:1 NAT with PA.

This is what I got after testing the services on 3CX (installed on Windows Server). It shows the mapping does not match although I've tried to NAT 1:1, port 5060 for example. Do you mind sharing of the screenshots of what you have configured on your Palo Alto for 3CX (blur sensitive info)? Thanks

 

[Evolute IT]

This is what I got after testing the services on 3CX (installed on Windows Server). It shows the mapping does not match although I've tried to NAT 1:1, port 5060 for example. Do you mind sharing of the screenshots of what you have configured on your Palo Alto for 3CX (blur sensitive info)? Thanks

View attachment 32318

Have you disabled SIP ALG?

 

[Jean-ChristopheC_3CX]

Hello,
SIP ALG is the only thing that is done correctly (see screanshot).
The problem here is the random ports.

We are sending the packet from the port 9000 and is coming back on 37371.
Look at this doc:
https://www.3cx.com/docs/firewall-checker/

 

[SweetAction]

This is what I got after testing the services on 3CX (installed on Windows Server). It shows the mapping does not match although I've tried to NAT 1:1, port 5060 for example. Do you mind sharing of the screenshots of what you have configured on your Palo Alto for 3CX (blur sensitive info)? Thanks

View attachment 32318

I'm sorry, we have PA's at several clients but I am not able to share their configurations here. That being said, your issue is likely with your NAT rule, it should look something like documentation https://docs.paloaltonetworks.com/p...les/destination-nat-exampleone-to-one-mapping
Pay attention to the destination translation.

 

[dkha126]

Thank you all for your kind response.
I've just got feedback from our vendor (they're also 3CX partner) about the SBC. I've attached again the system diagram which they suggested to us. We do have two direct lines from our Telco and will be plugged directly into SBCs without going through the internal firewall.
They said SBC in this case acts as a transfer point between 3CX and Telco, ensuring the call quality is stable. In terms of security, it plays as a firewall as well (layers 5-7). I'm not sure if this is the best practice yet.
Thanks.

 

[SweetAction]

This sounds like you have some Ribbon, AudioCodes, or similar "SBC" between the SIP Trunk and 3CX. This isn't needed typically, but can work if configured correctly. It can also explain the results from the firewall checker above as well.

This configuration is going to be really hard to troubleshoot without knowing all the details. Every "assumption" I can normally make I cannot make here.

Honestly, you need to either engage with the partner who designed this for all the unique issues you will run into (or another partner willing to deal with it) or switch to a supported, validated design. That includes only 1 NIC on the 3CX box (not 2 as mentioned above, 1 WAN 1 LAN), a supported provider (not an external SBC to connect to your trunk that may not be supported by 3CX), etc. I'm not saying this design can't work (it can), I'm saying that help on the forums or via support ticket is going to be limited and often non applicable because your setup doesn't match what is expected.

And to answer 2 other questions from earlier... no, this isn't best practice and yes, 3CX anti-hacking module is "good enough" without needing a filter in front of 3CX.