Change https port

[Nik_si]

Hello 3CX community,

I want to change https port instead of 443 to 5001.

I navigate to
sudo nano /etc/nginx/sites-enabled/3cxpbx
and change listen record.

after this I was able to enter 3cx management console with port 5001 instead of 443.
my extension was able to start a call...

but there is one problem, no history, no status, no presence..

what do I change also manually? I don't wont to re-install full system with changed setupconfig.xml file.

thanks!

in attachment is now 443 again, to work everything correctly.

 

[fxbastler]

Hello @Nik_si

I want to change https port instead of 443 to 5001.

I navigate to
sudo nano /etc/nginx/sites-enabled/3cxpbx
and change listen record.

That's a really bad idea: it won't be enough and it won't work as you've already discovered. Please undo the change.

The recommended 3CX way is: create a complete backup of the 3CX, download it, check the backup (e.g. whether it can at least be fully unpacked without errors), reset the entire 3CX system, start the initial setup using the previously created backup and then define the desired HTTPS port.

However, various previously provisioned devices will still not connect. They may still try connect to the former HTTPS port. They must be re-integrated.

 

[Nik_si]

Hello @fxbastler thank you for information.

Finally I want to achieve to have multiple 3CX server inside of 1 Public IP. so do you think is it possible?

https port is easy, every server will have it's own 5001,5002,5003...etc.

but what about 5060,5061, 5090? is it works with port-forward (to addresses = internal ip's of 3cx servers).

 

[bitn2]

That wont work as well... Think about all the other ports.. SIP Port, Tunnel Port and so on. One Public Ip for multipe 3cx instances isnt a good idea. If the functions from multi tenant is enough for your customers, this could be a solution for that.

 

[fxbastler]

Finally I want to achieve to have multiple 3CX server inside of 1 Public IP. so do you think is it possible?

Yes, it is.

This can work if there aren't too many 3CX servers behind a single IP address and if you use SIP providers where this isn't a problem. It also depends on what kind of 3CX services you use.

We use this approach: several 3CX are located behind a router with a reverse proxy, each in its own network and are operated this way. Therefore, all of our 3CX running there have the same HTTPS port but different SIP and tunnel ports. This can be configured during the initial setup or a restore. The RTP ports (start and end) can be adjusted later, e.g. via parameters or by making changes in a backup so that they don't overlap between the different 3CX. Often a large amount of RTP isn't needed per 3CX. You should also change the port settings in the 3CX firewall later.

 

[Nik_si]

@bitn2 to take full backup did you meant scheduled backup, right? (office/backup-and-restore location)

 

[fxbastler]

@bitn2

wrong user name

to take full backup did you meant scheduled backup, right? (office/backup-and-restore location)

Yes, for example, there. Use an existing full backup or create a new one.

The alternative is to create such a backup in a 3CX shell, which is also where a Debian 3CX rollback is done.

Download and test the backup, reset 3CX, start assistant.

 

[fxbastler]

This is a Windows 3CX and this describes a 3CX v18, but the procedure is very similar.

 

[fortech]

Hi Nik_Si, for what it is worth. Depending on the options you have / where the 3cx is hosted. You can possibly achieve 'nice dense multi-3cx' with less drama, long term maintenance, customization, if you go with the approach of

one physical host
hypervisor to slice up multiple VM
pay for multiple public IP address
allocate one IP address per 3cx instance/VM
that way you can do 'vanilla' 3cx with no customization, proxy, atypical ports, etc
you still get benefit of - efficient use of resources on one physical box
ie, many benefits "pros" and modest "cons"

I've got a 3cx hosting box setup in this manner, Proxmox hypervisor, LXC containers for 3cx, one public IP per 3cx instance. It works really smoothly, and has ~no customization needed once the base 3cx VM image is prepped and good to deploy.

given the modest incremental cost for extra public IP it is a nice 'easy and efficient' way to meet the goal of - more 3cx hosted in one physical server instance - better 'efficiency' more or less.

long term if your 3cx config has a significant amount of customization / then it might require more config-support-fun down the road after updates, etc. which is presumably avoidable if you simply go with 'stock 3cx install' (kind of) ?

just a thought!

Tim

 

[fxbastler]

LXC containers for 3cx

Definitely not. This is not a supported scenario under any circumstances. It is highly discouraged. If any problem ever arises, there will be no help available - except for a reinstallation in a supported environment.

It should be fully virtualized. My strong recommendation is also: if there are multiple virtualized 3CX behind one or more public IP addresses then install and operate each 3CX on its own RFC 1918 network.

 

[Nik_si]

@fxbastler what do you think if I will change listen ports in setupconfig.xml of SIP port, tunel port and etc.?

 

[Evolute IT]

Definitely not. This is not a supported scenario under any circumstances. It is highly discouraged. If any problem ever arises, there will be no help available - except for a reinstallation in a supported environment.

It should be fully virtualized. My strong recommendation is also: if there are multiple virtualized 3CX behind one or more public IP addresses then install and operate each 3CX on its own RFC 1918 network.

Don't bother. Some people just wanna do their own thing and then complain when issues arise.

Supported configurations exist for a reason lol

 

[Nik_si]

@ConceptsWeb what do you think if I will change listen ports in setupconfig.xml of SIP port, tunnel port and etc.?

 

[Evolute IT]

@ConceptsWeb what do you think if I will change listen ports in setupconfig.xml of SIP port, tunnel port and etc.?

Running multiple 3CX on the same machine, or on the same public IP, are not supported scenarios.

Be a good partner to your clients and don't mess around with weird setup.

There's so many deployment options already.

 

[fxbastler]

@fxbastler what do you think if I will change listen ports in setupconfig.xml of SIP port, tunel port and etc.?

Edit setupconfig.xml for a brand new 3CX.
During the init with the config wizard using a 3CX Backup.

Yes @ConceptsWeb :
The one and only supported 3CX environment is to use a 3CX with a own public IP without changing RTP Ports.
This means also if they are full virtualized (on the same host) in separated networks with a own public IP for every 3CX.

We're using a somewhat gray environment with a reverse proxy for HTTPS and only one public IP. But we have enough experience to handle it

 

[NicholasP_3CX]

@ConceptsWeb what do you think if I will change listen ports in setupconfig.xml of SIP port, tunnel port and etc.?

For a new configuration yes you can change the ports. But this is for a NEW deployment.

For version 20 the HTTPS port is 443.

If you need to change the HTTPS port of an existing machine, as has been mentioned it is a full backup and restore.

You can only have 1 3CX per IP address, UNLESS you are deploying to a MULTITENANT. This might be the best option for you to deploy multiple SMALLER customers which dont have elevated needs.

There is no need to reinvent the wheel when doing things in 3CX.

 

[fortech]

Definitely not. This is not a supported scenario under any circumstances. It is highly discouraged. If any problem ever arises, there will be no help available - except for a reinstallation in a supported environment.

It should be fully virtualized. My strong recommendation is also: if there are multiple virtualized 3CX behind one or more public IP addresses then install and operate each 3CX on its own RFC 1918 network.

Agreed and understood, LXC containers is not an officially supported deployment model from 3cx. That being said, (a) if someone has sufficient experience with LXC and can support it well, then - well - great. IMHO. (b) as you say, the easy recovery path if drama arises - is to nuke the LXC container, deploy a KVM_fully virtualized VM instance, do a clean install of 3cx inside there and restore 3cx config from backup. Since the IP / network topology is exactly the same here (ie, Proxmox does not care if you allocate a public dedicated IP - to an LXC vs a KVM guest) - then functionally 'not a lot changes' other than - 3cx is running inside a full kvm virtual machine instead of a slimmer lxc container. And the so-called-recovery-path is well defined, well understood, etc.

So, All that to say. "yup". And for the record, 3cx so far is a really great LXC tenant app/stack in my experience to date (ie, ~9months now). But that does not mean it is supported by 3cx, nor that other people may expect the same success, ie, your miles may vary, and the lxc path may be terrible for some people where for others it may be amazing. etc etc. So. All good as long as a good operational platform is provided, which runs reliably and consistently, and has no management issues, operational issues, etc. And of course good regular VM/container backups of the stack help ensure easy good rollbacks can be achieved, regardless of separate 3cx backups etc.

ie, end of the day from (only!) my perspective, running 3cx in LXC / with each instance having its own dedicated public IP / is a very different decision from trying to run multiple instances of 3cx on a single server (physical or virtual) with a single public IP / and reverse proxy FQDN slice-and-dice to try to 'make it all work normally' under the hood. ie, 3cx is inherently less easy to do this with than say, web site hosting where all of your traffic (typically) is via very few ports (ie, http/https 80/443) and in such a reverse proxy config it is ~comparatively easy to put many FQDN on a single IP address / and let the reverse proxy sort things out for the different 'back end web server instances'.

hopefully it is ~good that discussions like this help to shed light on what is good / what is supported / what is not supported / what is / not / recommended vs easy vs possible vs 'technical challenge adventure time'. Maybe?

Tim