PMS Integration outside LAN

Status
Not open for further replies.

E. Sparks

Customer
Joined
Apr 2, 2017
Messages
2
Reaction score
0
I am attempting to integrate the PMS via Mitel SX2000 integration where 3CX is cloud hosted.

I've configured the Hotel Services section with a port of 4001 and forwarded 4001 through the customers firewall to the PMS.

I've verified that the port is open into the customer's LAN from the 3CX (ssh'd in) using nmap, telnet, tcpdump etc.

Port 4001 is open locally on the 3cx when Hotel Services is configured, I can nmap -p 4001 localhost on the 3cx and it returns open.

There is no firewall enabled on the cloud hosting provider however 4001 is not open via an outside host. The cloud provider is receiving the request, I can see it come in via tcpdump.

This seems to be true of version 18.0 (Build 314).

However another customer on version 16.0.16 shows 4001 open for hosts outside of the LAN when configured the same way.

Is there a way to configure firewall rules for the Hotel Module specifically?
 
When configuring 3CX with the Mitel SX2000 PMS integration, the 3CX PBX will act as a server, meaning that the port you are configuring, in this case 4001, will be the port 3CX is listening on for a connection from the PMS. The PMS will most probably be using a different source port so I'm not sure why you forwarded port 4001 through the customers firewall to the PMS. Are you referring to outbound traffic from the PMS directed to the 3CX PBX? Or have you perhaps configured the PMS to use port 4001 as the source port too?

I've verified that the port is open into the customer's LAN from the 3CX (ssh'd in) using nmap, telnet, tcpdump etc.
Is this testing traffic from the 3CX PBX to the PMS on port 4001? You might want to check the reverse traffic, from the PMS to 3CX on TCP port 4001.


There is no firewall enabled on the cloud hosting provider however 4001 is not open via an outside host. The cloud provider is receiving the request, I can see it come in via tcpdump.
This I'm not 100% sure I understood, are you saying that traffic to tcp port 4001 is not reaching the PBX? If yes then this is the issue. Which hosting provider are you using, is it a 3CX Supported one? Also, how was the 3CX PBX deployed, via the 3CX ISO, hosting provider's market place, customer portal wizard or manual install?
 
I assumed that communication would need to be bidirectional so I had opened ports for both sides of the connection. Now I understand that is not required.

Upon further investigation I found that the port was blocked by the nft firewall on the 3CX machine.
I was able to open the port by editing /var/lib/3cxpbx/Bin/nftables.conf
and adding 4001 to the tcp dport sections.

I originally had this instance 3CX hosted. Once I ran into this issue I assumed it was firewall related and since there was no way to alter the firewall on a 3CX hosted machine I attempted to move the machine to AWS self hosted, but was not able to get past the "No machine types available for your account in the selected region. Try another region or open cloud provider portal and check that you can create machines in the selected region." error message within the 3CX portal.

I then attempted to launch a clean 3CX instance with the newest V18 3CX instance from AWS Marketplace. After a fresh install 3CX services would not launch:
Dependency failed for 3CX PhoneSystem 01 Management Console.
systemd[1]: 3CXPhoneSystemMC01.service: Job 3CXPhoneSystemMC01.service/start failed with result 'dependency'.....

Ultimately I installed a fresh copy with the Debian ISO onto a Linode instance, which appears to be working fine now.
 
I'm not sure why you had issues deploying in AWS but I'm glad you managed to bring the machine up in working condition in the end.

I do have to mention though that the provider you used is not a 3CX Supported one so I can't say I recommend sticking with the instance at hand especially if the 3CX ISO was not used to deploy it. I understand that you already tried using a 3CX Supported config so I'm just mentioning this because I think that at some point it would be worth looking into why the deployment failed on AWS so that you can maybe plan migrating in the future.
 
Status
Not open for further replies.

Forum statistics

Threads
111,974
Messages
590,083
Members
164,901
Latest member
Silent_Guru