Solved changing RTP ports, modifying nftable rules - persistence?

[cubewerk]

Hi,

we're running two 3cx behind a single public IP. I succesfully changed the RTP ports of the second pbx with FIRSTEXTPORT + LASTEXTPORT.
And tuned /var/lib/3cxpbx/Bin/nftables.conf accordingly.

Is anyone else doing it this way and is this a stable approach? Will it survive an update/upgrade?

Input is highly appreciated.

Thank you.
stefan

 

[VasilisV_3CX]

Hi @cubewerk,

The only input I can give you is that this isn't supported or recommended, nor intended.

 

[cubewerk]

The only input I can give you is that this isn't supported or recommended, nor intended.

So what is the recommended way to have several pbx behind a single ip?
I'm certain that no cloud hosting provider will spin up a single ip for each customer either.

 

[VasilisV_3CX]

Hi @cubewerk,

I'm afraid that we don't recommend having multiple PBXs behind a single IP.

 

[bitn2]

That will cause a lot of problems and doesnt make any sence. Sure you will get your own ip at cloud providers. How do you reach your cloud without an ip?

 

[cubewerk]

That will cause a lot of problems and doesnt make any sence. Sure you will get your own ip at cloud providers. How do you reach your cloud without an ip?

Only because you do not see a benefit at first glance, there are some for us So it make sense. Sure it's all nice and clean when you can spin up an ip per pbx, but as v4 ip's are rare, we want to share IPs. You might have heared of port translation. Thats how one can reach it's pbx behind a single/shared ip by having different ports.

 

[bitn2]

Sure you can do this, but port translation is not really good with sip. You cant do 5060->5064 or something like this without problems. What you can try is 5060->5060 and 5064->5064 and so on. But its not supported nor recommed.

 

[cubewerk]

Sure you can do this, but port translation is not really good with sip. You cant do 5060->5064 or something like this without problems. What you can try is 5060->5060 and 5064->5064 and so on. But its not supported nor recommed.

I'm not talking about port translation for the sip ports and stuff. 3cx already allows by default to just setup independent ports. I just explained to you why you do not need a single ip per customer to let them reach their pbx.

But back to the the topic, i see no technical reason, to not be able to specify the RTP-ports as well. If done correctly, it's just another range of ports.

 

[bitn2]

Doesnt matter sip or RTP ports. Port translation doenst work. Anyway you answerd your question by your self. Your custom changes could be broken after an update and it is not supported by 3cx.

 

[Alphabetic]

Easy solution.. buy another IP.

 

[cubewerk]

Doesnt matter sip or RTP ports. Port translation doenst work. Anyway you answerd your question by your self. Your custom changes could be broken after an update and it is not supported by 3cx.

You still dont get it right. I just mentioned port translation for the management of the pbx itself. That was all you were talking about first. Please dont mix up things. This forum should be a place for others to find answers and not just opinions. "Doesnt matter, doesnt work, makes no sense.". Thats just low level input without any help.

 

[cobaltit]

You've already gotten your answer. It's not recommended or supported by 3CX, thus no one knows if it will survive an upgrade. But like anything else done outside the box, if you know how to do it, you know how to support it. So the question of 'will it survive' is more just a question of convenience for you since worst case scenario is you will have to 'fix' it again which you apparently know how to do. So if you are on some sort of virtualized infrastructure you can snapshot, upgrade, test, and if it doesn't persist, either fix it or roll it back and plan for doing the upgrade when you can afford the downtime to test/fix.

 

[bitn2]

You still dont get it right. I just mentioned port translation for the management of the pbx itself. That was all you were talking about first. Please dont mix up things. This forum should be a place for others to find answers and not just opinions. "Doesnt matter, doesnt work, makes no sense.". Thats just low level input without any help.

Port translation for management cant work as well. You need the ports for presence and more. You can try to use for every pbx a different https port. But anyways, not supported or recommend. Just my two cents and I am off now.

 

[NickD_3CX]

To cut this conversation short, I think the most complete and to-the-point answer is this one:

You've already gotten your answer. It's not recommended or supported by 3CX, thus no one knows if it will survive an upgrade. But like anything else done outside the box, if you know how to do it, you know how to support it. So the question of 'will it survive' is more just a question of convenience for you since worst case scenario is you will have to 'fix' it again which you apparently know how to do. So if you are on some sort of virtualized infrastructure you can snapshot, upgrade, test, and if it doesn't persist, either fix it or roll it back and plan for doing the upgrade when you can afford the downtime to test/fix.

It covers the 3CX position 100% on this matter.