Mutli Nic setup

[Ryztech]

So I'm a new partner working on my first local deployment ( I have a few remote) and wanted to get some opinions on what everyone does for local deployments. I have the 3cx Debian running on a local server with a dedicated static IP. I wanted to separate the phone from the lan to make sure there was no issues with firewall or nat. This would normally be fine because other clients would use the 3cx app/chrome extension however this client is difficult and wants to continue using his Bria 5 Soft-phone which is causing some issues I can only assume is related to sip over public internet from my research.

So opinions on what to do since this system is still POC and not system critical

I was thinking about adding a new NIC so that the system can function on the public IP for all remote users with no firewall and nat issues and the other NIC be local so I can use that for all local IP Phones and Softphones. Is this something that can be added after the fact or would I need to re install the application in order to add the new NIC.

Ive looked over the docs and this looks like it could be done but want to make sure im doing best practice.

What would you guys recommend I do? Should I add an SBC or just suck it up and put the server behind the nat.

Thanks in advance

Ryan,

 

[Evolute IT]

You don't need multiple NICs.

Configure a VLAN for data and voice, then plug the PBX and phones on the voice vlan.

After that, configure your NAT forwarding for the required ports (found in the docs) and forward them to the VLAN PBX IP.

This way, remote users can use Bria or the 3CX App, and local phones can still talk to the PBX.

Then, just make sure you have a rule allowing traffic between the data and the voice vlan so that local users can use the Webclient with or without the FQDN.

 

[Ryztech]

You don't need multiple NICs.

Configure a VLAN for data and voice, then plug the PBX and phones on the voice vlan.

After that, configure your NAT forwarding for the required ports (found in the docs) and forward them to the VLAN PBX IP.

This way, remote users can use Bria or the 3CX App, and local phones can still talk to the PBX.

Then, just make sure you have a rule allowing traffic between the data and the voice vlan so that local users can use the Webclient with or without the FQDN.

That would require putting the server behind the router and nat. The original goal was to prevent having to deal with nat for any external traffic and allow internal traffic to use the local ip. That's probably what ill end up doing if I have too but I would prefer to keep external traffic out of the internal network so I have the least points of failure.

 

[Evolute IT]

That would require putting the server behind the router and nat. The original goal was to prevent having to deal with nat for any external traffic and allow internal traffic to use the local ip. That's probably what ill end up doing if I have too but I would prefer to keep external traffic out of the internal network so I have the least points of failure.

I would not recommend that. You want a firewall in front of it for increased security.

Also, NAT won't be an issue if you configure the firewall ports correctly and disable ALG. External traffic will then be forwarded to the PBX without issues.

As for points of failure, the best for this is to put the PBX in the Cloud and use an SBC on-site. Otherwise, you will always have points of failure (ISP, power, weather, etc.)

 

[Ryztech]

I would not recommend that. You want a firewall in front of it for increased security.

I am well aware of how to secure a public facing application. You can have a firewall without being behind NAT. When you run a cloud based PBX that's all you are doing is exposing the whole server to the web behind a SDN firewall so it would be no different than my plan.

Also, NAT won't be an issue if you configure the firewall ports correctly and disable ALG. External traffic will then be forwarded to the PBX without issues.

The client requires a very specific set of security restrictions for that reason alone we can not have external traffic for the PBX going thru the network regardless of VLANs. Secondly why would anyone want to push extra unnecessary traffic thru their network?? Its just more load on the routers and switches that isn't needed and isn't good practice let alone the security extra risks that come with it.

As for points of failure, the best for this is to put the PBX in the Cloud and use an SBC on-site. Otherwise, you will always have points of failure (ISP, power, weather, etc.)

Luckily I plan ahead and the client has already got redundant networking, ISPs and backup battery so the only thing taking him offline is a massive natural event that takes him or both ISPs out, since we have gone as far as making sure they route us thru different physical locations on the different providers it would need to be a fairly large event.