Hotfix for Public Interface/Default Gateway Installs

[AndreasP_3CX]

The Update 8 issue affecting installations where the Public IP interface is selected as the default interface during installation has been resolved. A hotfix has been rolled out. During the investigations Update 8 was temporarily paused. It’s important to note the following installations were NOT affected:

• 3CX Hosted - PRO /ENT
• 3CX F...

• Continue reading the Original Blog Post.

 

[SteveITS]

> In v20 provisioning ip-phones with method stun will be removed.

I don't disagree but this is the first I've heard of that. We have one client who didn't take our advice to set up an SBC for their 3 phones. Luckily they have Yealink 5 series so we can convert them.

 

[mcsphones]

> In v20 provisioning ip-phones with method stun will be removed.

I don't disagree but this is the first I've heard of that. We have one client who didn't take our advice to set up an SBC for their 3 phones. Luckily they have Yealink 5 series so we can convert them.

I just posted a thread about this too; https://www.3cx.com/community/threa...sioning-going-away-in-v20.121956/#post-570786. We have a few handful of people for a desk phone at home. Works well, but it's just a handful thankfully.

 

[SweetAction]

I'm in middle of posting a thread on the same thing. I'm hoping this restriction is ONLY for 3CX hosted and on-prem, self host are unaffected.

 

[mcsphones]

I'm in middle of posting a thread on the same thing. I'm hoping this restriction is ONLY for 3CX hosted and on-prem, self host are unaffected.

Right; I'm going thru our customers and quite a few have a Stun phone or two; we have one I mentioned in the thread that has communication to their stores across the US all with Stun, and it is working great for them so that could be a problem.

 

[N_G]

Stun technology simply doesn't work well and creates support issues.

We will not do any hard remove but not promote it in the interface. The comment was meant that you try to use router phones where possible. Many phones can be converted to router phone - yealink t5 and t4 and all recent fanvils. Snom has a great looking d8. So you can easily create a reliable environment for the customer. The customer experience will be much better.

 

[mcsphones]

Stun has been unsupported for a long time.

Yes sir, it has been. I don't disagree with that. I just want to be able to maintain existing functionality for customers; we can sell router phones for any new scenarios where Stun otherwise might have been used. But I think keeping the functionality available for on-prem installations, knowing they aren't supported, would still be preferred. Thanks!

 

[ltri37]

I'm hoping this restriction is ONLY for 3CX hosted and on-prem, self host are unaffected.

On-prem is self hosted.

For 3CX there is only "3CX hosted/cloud" or "on-prem". If you have access to the OS, you are on-prem for them. Whether this is your private Cloud or a public Cloud or something else does not really matter.

Those are the assumptions on the 3CX side: there are only two network configurations and the partners and customers are unable to configure basic networking.

Like the expression "Split DNS". Can we stop talking about "Split DNS" and talk about the actual requirement, which is Full access via FQDN? Split DNS is a solution to achieve FQDN access in a particular network configuration, that's it.

We need Call Flow Apps, we need CRM integration with third party CRMs that often are *not* local, and we can't just make another company expose a private CRM system on the Internet, we do need VPNs for that.

None of this can be achieved with hosted 3CX solutions. None of this can be achieved with a SBC.

Just because we have a public IP on the interface does not mean we are without a firewall.

Just because we are not using "3CX hosting" does not mean we are on the customer premise.

Vice versa just because we are on the customer premise doesn't mean the customers CRM is on that same premise. Maybe the CRM is in the cloud?

Just because we are on premise does not mean the SIP Trunk towards the PSTN network can use the same NIC than the local phones.

I understand the need for 3CX to "dumb it all down", but please understand that your partners need to respond to complex enterprise requirements and that sometimes partners actually DO know what they are doing.

The requirement for full FQDN access is fine. I wish you'd stop calling it Split DNS, but it's fine, we will implement it and it does makes sense (considering certificate/TLS use, etc).

But we need to know if 3CX is going retire multiple NIC support completely (even though we make FQDN access happen for all involved devices, a.k.a. "3CX Split DNS") ? You are not currently saying that directly, but what happens when you introduce the next bug related to multiple NICs, will you then suddenly claim that multiple NICs are not supported?

Will we be able to interconnect with a CRM from a secondary NIC in V20 or will this be "not recommended" and may suddenly brake?

Will we be able to interconnect with local phones in V20 with a correct "Split DNS setup" even though it uses a second NIC or will this be "not recommended" and may suddenly brake?

 

[Gilles (Transacom)]

Stun has been unsupported for a long time.

It may well be the case, but it works fine and is useful in quite a few cases. Requiring to change existing working configurations and requiring changing phones or adding SBC in order to be able to stay up-to-date will be more than problematic with quite a few customers.

 

[richiewhite]

My two cents (besides that we'll need to manage upgrades to v20 very carefully depending on the decisions made about existing deployments using STUN), is that in our experience we have clients running DECT only physical deployments between multiple locations, however until there's a DECT base that works as a router-phone (we supply Yealink) we'd be in the situation where we have to require our end-clients purchase a compatible phone that they don't want, or set up an SBC. STUN has worked very well for this use case for us until now. I'd much prefer that the ability to provision be kept based on an understanding that it is not supported by 3CX.

 

[SweetAction]

On-prem is self hosted.

My comma (which is missing) is before the "on prem". That statement should have read:
I'm hoping this restriction is ONLY for 3CX hosted <comma here> and [people who are] on-prem, [or] self host are unaffected.

I'm assuming your post isn't directed at me (just the first sentence is), but I fully get the "let the power users do power user stuff". Trust me, I'm the power user. 95% of the people in this forum are telecom people, I'm actually a systems/network engineer that does telecom because IP Phones are just specialized PCs these days and SIP is just another protocol (like TCP). I do "dumb it down" when posting because if I were to not do so, I'd be talking to myself half the time.

Feel free to read through my post history and you'll find plenty of proof. 3CX employees can check my ticket submission history - 2 tickets in the 5+ years I've been with this company (14 years selling 3CX), 1 which someone else submitted before talking to me and 1 which was a confirmed bug report.

I do agree with what you are saying though. I also understand that 3CX is trying to reduce support load, and so by making the phone system "Fisher Price", they can. It hurts those of us with complex needs, which is why you'll often find me advocating for leaving the "power user" functions in, but marking it as unsupported if need be. See my posts about DHCP option 66 support as an example. Or this thread is another example - I get they don't want to support Direct SIP (calling it STuN is also wrong, because STuN is simply a technique used here to determine the public IP of an IP Phone) because many routers that are not NAT friendly to VOIP devices, but I still asked for it to be available to the power users - the ones that run on-prem/self hosted (which is the same thing, but 3CX has 2 separate forums for it so it's not the same to 3CX). I only ask for official support when it's a system bug (although I'll post on the forums more often).

 

[ltri37]

@SweetAction correct, only the first sentence is in response to you.

In terms of VPN we meant using VPN for the phone - this is overkill for most installs.

VPNs just scale extremely well, both up and down.

I have deployments with single Yealink DECT station at one site that openvpn's directly into a VM (I avoided Direct SIP / STUN). That's a single device (the DECT station) at the customer site.

I have a single Yealink T31 that openvpn's into a VM. And sometimes the customers picks up the Yealink and brings it home. You are going to shake your head for the customer not using the app. You and me both.

Those deployments need to work for a few years, before we can convince the customer to spend additional time (money) for replacing them with new HW (and SBC support). And something things work just fine and there is little incentive to throw out perfectly working hardware just for the sake of updating to a newer release.

The end customer is not on the bleeding edge, that would mean re configuring the sites every 6 months, which would ever be affordable.

On the other hand regarding VPNs (other than interconnecting private CRMs) are large customers sites with 300 extensions that need connectivity with a carrier class device, not a Raspberry PI and not a server or a VM. We moved to (our) cloud to avoid having to deal with raspberry Pis, servers and VM's on site. VPN's allow us to do this.

In general of course VPN is required - does the server have to run on the pbx though?

Well, deploying a single VM with a single public IP that can do it all for a specific customer is one thing.

If the same customer needs a virtual datacenter with multiple public IPs and a VPN gateway, this increases complexity and cost. A lot a lot.

Where possible these core services should be separated in our view. Any case you can manage it yourself of course.

You are saying that because you want to streamline deployments and not get trouble tickets for those VPN issues that you don't have any control over. This is perfectly understandable.

But the VPN interface is really just another NIC on the VM, if you keep supporting mutliple NICs, you don't have to worry about VPN's.

We can rename our virtual tunnel interfaces from tun0 to eth2 if that makes life simpler for your support department, because that is all it is


On Windows, you just provide the software. On linux you provide an entire OS stack. Actually I was thinking if it wouldn't be a better choice to just deliver a docker container for linux deployments, as opposed to delivering an entire OS.

This would abstract away some of those issues (always a single NIC with a single private IP).

But that ship has probably sailed, considering that everyone is used to VM's now.

10,000 plus partners with varying skill levels.

Oh I get what you are saying, absolutely. I do think skill levels like sweetaction and myself has are not the norm.

But maybe the support scalability problems are coming from unlimited free tickets for silver and gold partners?


I'm a little scared when I'm reading blog posts that custom templates should really not be used, when actually we need to replace DECT templates (directly on the filesystems as DECT/FXS templates can't be edited from the admin console) every time we upgrade, due to the severe security issues in the default templates (you can factory reset or even worse completely isolate a Grandstream FXS gateway from your hotel room without any previous knowledge).

 

[Gilles (Transacom)]

Thanks @Nick Galea for your answers. I'd like to add that non supported capabilities that work just fine, like STUN or custom templates, is what allows skilled partners to support on their own configurations that would not be possible otherwise, and therefore customers that would not choose 3CX. Requiring partners who do that to support from a to z is normal. Removing such features to make the product easier to maintain but less capable will be a loss for partners and for 3CX...

 

[Gbot@Okam]

Point taken on the VPN. Just use only where necessary and support configuration a to z. Custom templates same. Re gateway configs we are removing those, they need to be created and supported by the gateway vendor.

Hi @Nick Galea
You've recently made a bunch of very painful changes, sacrificing many useful functionalities by just arguing "this is security".
I'm scared reading @ltri37 post on what 3CX forces with the template on FXS, introducing MANY security flaws.

You should really consider trusting your partners, and let them customize templates if needed (and it's often necessary).

 

[SweetAction]

Hi @Nick Galea
You've recently made a bunch of very painful changes, sacrificing many useful functionalities by just arguing "this is security".
I'm scared reading @ltri37 post on what 3CX forces with the template on FXS, introducing MANY security flaws.

You should really consider trusting your partners, and let them customize templates if needed (and it's often necessary).

And 3CX allows you to customize the templates so we can change what we need to...

 

[ltri37]

For Phones you can, you can't do that for DECT/FXS Gateways. You need to modify the files on the filesystems which will be overwritten by software updates.

 

[SweetAction]

For Phones you can, you can't do that for DECT/FXS Gateways. You need to modify the files on the filesystems which will be overwritten by software updates.

Correct. But back it up, update, restore.

I haven't checked in a hot minute, but I think it only overwrites the existing files. A completely new config file in that folder may survive updates.

 

[ltri37]

That's what we are doing (diffing every update and applying our changes again).

I don't think you can reference a different config file in that folder. Filenames for DECT/FXS templates appear hardcoded to me.

 

[SweetAction]

That's what we are doing (diffing every update and applying our changes again).

I don't think you can reference a different config file in that folder. Filenames for DECT/FXS templates appear hardcoded to me.

I was able to add a fake W70B a few updates back for a customer. Maybe the name needs to be the same, I forget. I can look into it further if need be.

 

[ltri37]

I will give it a try next week, thanks for the hint. Maybe it's just picking up all the files from the folder and we just need to change the unique identifiers in it for it to appear. Thanks.