Seeking assistance on 3cx V14 test deployment.

[plosp023]

Hello,

I was demoing the v14 3cx edition. ( virtual PBX which has to be deployed on a virtual machine. ) I had a few questions that the guide / reference examples never went over.

During the installation you will be promtped for the FQDN / sub domain to use for this deployment. ( Basically prevents you from using the ipv4/v6 address instead. ) That is all fine and dandy, since it seems each instance will have a different SIP listening port. ( So FQDN:xxxx can serve many virtual sip servers. )

My worry is the console mgmt for each instance. It seems you can't configure each instance's web port, so it would be just as simple as: FQDNort for access. Instead when you "launch instance" it loads the sub domain on port 80. ( So it's instance1.yourdomain, instance.yourdomain, however it simply adds these to your hosts file, pointed towards 127.0.0.1. )

So within 3CX you can open each instanc#.domain:80, but would require some sort of proxy within windows to allow external access to each instance's web console. ( Even if it's a real domain in your internal DNS, DNS doesn't understand port numbers. It should increment the web port to make it easier. )

Has anyone solved this yet?

kind regards

 

[Anonymous]

As I understand it, the Web-based management has been consolidated under 80-443 for all instances. For public Access, you still have to configure public DNS for that Instance name. i.e. <instance name>.<Servername>.domain.com. So all instances will point to the same IP. This is as easy as a CNAME for the instance.server.domain.com back to the <Servername>.domain.com or an A record directly to the IP.

The host file entry is made on the server when you create the instance so IT knows where the instance is even if you haven't created the public DNS entries yet.

 

[plosp023]

Hello Matrix8,

thanks for your reply.

"As I understand it, the Web-based management has been consolidated under 80-443 for all instances. For public Access, you still have to configure public DNS for that Instance name. i.e. <instance name>.<Servername>.domain.com. So all instances will point to the same IP. This is as easy as a CNAME for the instance.server.domain.com back to the <Servername>.domain.com or an A record directly to the IP."

I understand that, but setting instance#.name.domain as a DNS entry some where pointed to the host IP doesn't solve my issue or problem. It doesn't really make sense to run several web instances on the same port and IP without some sort of proxying. ( of course the local host can load them, as it assigns 127.0.0.1, 127.0.0.2, and so on. )

external - both instance records (instance1.test1.com / instane2.test1.com ) point towards 10.0.0.2 ( obviously just used as a test. ) There needs to be something proxying / similar within the 3cx server to serve that up.

If that is the way it was designed that is fine, I will have to find my own solution for remote MGMT. I see many other related forum posts though, maybe I'm missing something simple.

kind regards

 

[Anonymous]

It's not proxying or anything like that. IIS is parsing the Host header (instance1.tes1.com vs. instance2.test1.com) and redirecting that to a different virtual directory. Yes you are connecting to the same IP but the Webserver is "routing" between virtual directories based on the HTTP request.

So publically, all of the instance names will get pointed to the same IP. When you visit each one, IIS knows which management page is which based on the management webpage that you request.