Qr code android app registration failure

[John Mitney]

Installed v.16 3CX on windows mashine inside the local network behind a microtic NAT. I opened all ports according to the instructions, everything is green in the firewall test, there are no problems. But I cannot register with the android application by the qr code from the local network. In android, the error says that I need to connect via QFDN, but how can I connect via QFDN from the local network? It is not clear to me why registration on the IP address of the 3CX server in the local network is not going on, it would be more logical. I tried to open the panel with the qr code both at the QFDN address and at the local adress, there is no difference. How can I connect with the application if my server is on the local network?

 

[nobody]

I thought the Mikrotiks are able to allow an outgoing connection to come back through the opened NAT ports (this feature is called "loopback" sometimes). But I do not manage Mikrotik frequently so I dont know if this should work out of the box with a default simple configuration. However if this does not work you still can setup a DNS zone for the local network which pointers for the FQDN of the PBX to the local IP addresses. That would be a good thing in any case to make access to the pbx easier for clients and administration.
Check the Mikrotik wiki pages for setting up a local DNS server on the Mikrotik. You also could try to install the V18 version of the pbx which has a workaround for this built in. No need for setting up a local DNS zone any more.

As an alternative provisioning method, download the attachment in the provisioning mail and open it on your phone. Maybe this makes a difference.

 

[John Mitney]

I thought the Mikrotiks are able to allow an outgoing connection to come back through the opened NAT ports

Thanks for the answer, I have little experience with mikrotik and 3cx. I tried to configure NAT LoopBack but did not get any positive result, maybe I need to contact a more advanced microtik specialist

However if this does not work you still can setup a DNS zone for the local network which pointers for the FQDN of the PBX to the local IP addresses.

This is probably the most correct decision.

You also could try to install the V18 version of the pbx which has a workaround for this built in.

I installed the 18 beta version on debian, but did not find any differences, I still did not understand what was added. I tried to set up version 18, but the result was the same

As an alternative provisioning method, download the attachment in the provisioning mail and open it on your phone. Maybe this makes a difference.

This one just surprised me. From the browser I can go to the server locally, from the phone only by FQDN and it shocked me, I cannot understand why the developers did this

 

[nobody]

"From the browser I can go to the server locally, from the phone only"
You mean, you dont understand why there is no additional challenge besides the cryptic URL before accessing the provisioning data? this applies to the Barcode method also.
There is already a discussion regarding this from time to time in the forum, but 3cx currently still says the cryptic url is as good as a password - which most likely is true.
However, giving out login data over an unencrypted channel like Email is another thing. 3cx will maybe tell you if dont feel good with this method, to provision the phones in an controlled environment.

 

[NickD_3CX]

In android, the error says that I need to connect via QFDN, but how can I connect via QFDN from the local network?

What you can do, while in the Local LAN, connect to your 3CX Management Console with https://<Local IP Address>:<HTTPS port> .
Wen logging in you will get an browser warning due to you using HTTPS but not the FQDN, but if you ignore and proceed and then scan the QR code, you will be able to provision your Android in the Local LAN as well.

In case you are wondering, when logging into the Management Console with:

• https://<Local IP Address>:<HTTPS port>
• https://<FQDN>:<HTTPS port>

The QR codes are different, in the first case it tells the phone to try and contact via the Local IP address, in the second case via the FQDN.