login Issues with logging in with the softphone, App and browser after V68 to V69 upgrade.

[CTel]

We have discovered that there are login difficulties with apps, softphones, and browsers following the change from v68 to v69. The majority of our users are now impacted, thus we had to provide an opensource, free option like Zoiper or Microsip. It functions perfectly with these programmes, however Vodia, Softphone, and Weblogin do not.

We are still experiencing problems and are expecting that the Vodia team will be able to provide some sort of resolution. Downgrading the pbx does not work either.

If you have any information about similar kind of issues that have been solved, kindly post a reply. Thanks

[Vodia PBX]

A typical problem with the upgrade are unresolvable DNS management addresses (see https://doc.vodia.com/docs/release-notes-690). Another thing that is causing issues is that the new version is a lot more restrictive regarding sending sensitive content over unencrypted connections. I know it's a pain, but sooner or later entering a password in plain HTTP will be very hard anyway. 

The new version has a way to explicitly set the admin password with the options --admin-username and --admin-password. There is no more need to exit the pbx.xml file, which was inconvenient and—depending on the tool used—even dangerous. 

Also, you should make sure that the PBX can send emails out and that there are email addresses set for the accounts. The password recovery email can then be used—like with most web services today—to get access to your accounts.

[CTel]

We are on version 68 atm, problem started appearing after the version 69 update, but then we revert back to 68 again, hoping that the problem would not appear no luck, but the login issue still persist. No DNS resolve issue as all the dns addresses are resolving as per required, and have no issues in loading pages.

 

[Vodia PBX]

Is the tenant address of the PBX a DNS address? How about the address for the system? Do you have a certificate, so that you can use HTTPS? Is this server on a public IP or a private address? 

[CTel]

the tennant addresses are subdomains, the system as soon as tennants are created, yes the system url address has https enabled from R3 (Lets encrypt), this server is on a public IP transit, and is resolving as per normal, not sure what could be the problem, should we downgrade to 67 and check ?

[Vodia PBX]

Hmm this should work. As usual, you should make a backup before such an upgrade so that if it does not work you can easily revert. Anyhow, when you log in please make sure that you are really on HTTPS so that the browser does not interfere with sending the credentials. You could also take a peek at the browser inspector network traffic if anything is being blocked, e.g. by CORS policy. Also another common problem with the login after the 69 upgrade are customized welcome.htm pages which don't work in 69. In that case, you can login through in through the rawlogin and revert the welcome.htm page.

[CTel]

Yeah Thanks for the information, i also wanted to confirm that new clients and tennants created post issues are having no login issues, only those with old clients which were there pre update. for eg: if i create any new tennants now i will not have any issues with softphones or login from webpage and so on. im guessing some files or folders for tennants or domain file after the update has failed to work, can it work if i could overwrite tennant and domain folders from older back up directly in the server in the usr/local/pbx folder ? 

[Vodia PBX]

The new version 69 login brings a couple of major features like the ability to use passkeys. That required a redesign of the form, which is causing problems when the welcome.htm was changed in version 68. What we have learned so far:

• If you have problems logging in to 69, try the rawlogin.htm page which used the good old primitive username and password to log you in.
• Don't put garbage into the "System management DNS address", version 69 uses it to fend off robots that don't even know the address of the system. Instead either leave it empty or put a DNS address there that resolves to the PBX.
• Make sure that you don't have customized the welcome.htm, and possibly reset the customization of the page.
• Consider just changing the welcome.css instead of the welcome.htm. There are beautiful possibilities in CSS if you just want to change the image that you see at the login.
• If it all fails, don't edit the pbx.xml file. Instead in 69, you can use the --admin-username and --admin-password option for manually starting the PBX (make sure you stop it first).
• Using HTTPS for any form that requires a password is becoming a requirement in many browsers, consider using a DNS address and use a certificate.

[CTel]

Hello, Thanks for your input, the following issue got resolved for me by going to Tennant >> Settings >> Groups (edit the group and enable / disable) permissions.

[mskenderian]

I constantly see same issues across the board. We should have a command line and a web interface to check for common issues.

A command to run / web page to visit to check if tenants domain name are resolvable. SSL certs are valid. Blah blah blah.

the most expensive and most frustrating items are all related to support. Making it easy to figure out what the problem is will fix the issues faster and resolve extra support tickets.

My most taxing task are support, I am sure Vodia is the same way. Server is cheap, routes are cheap, PBX software is cheap. Support is expensive.

With that being said, improving the log view would be critical. Like a way to filter the logs from the web gui. This will help identify the issue faster.

[Vodia PBX]

Total agreement on minimizing support. We want to offer a lot of functionality, and that is in conflict with the goal of minimizing support.

For example, one time killer is the onboarding of users. This is why we have been working on the logon experience without passwords, because passwords are not only a huge security problem but also cost a lot of time for admins as well as the users themselves (hacked systems are an extreme example of lost time spent on fixing everything). At the risk of being on the leading edge we decided to use passkeys instead of 2nd factor, and we believe that soon this will be mainstream and we don't have to educate users any more. 

Other topics are more tricky. For example, we have added many features for LAN provisioning that look outdated today. Should we silently drop them? Or set the defaults so that the LAN deployment becomes the one that requires extra work? We have started to add some hints like changing ports but not actually doing it. Should we by default set he "IP routing list" to "private public"?

The answer might lie in providing VM snapshots where everything is setup already, like for Amazon EC2. But even there, you still need to get a DNS domain for the tenant, the Amazon EC2 address will not work with Lets Encrypt. We had a lot of problems with admins using the same DNS address for the whole server as for one of the tenants, and hopefully have that sorted out in the latest builds. 

"Make everything as simple as possible, but not simpler" (Albert Einstein) might be the right motto.

[mskenderian]

4 hours ago, Vodia PBX said:

At the risk of being on the leading edge we decided to use passkeys instead of 2nd factor, and we believe that soon this will be mainstream and we don't have to educate users any more. 

I dont want to educate my users with passkeys, let the every app do that, when i see its mainstream I will just enforce it, until then please have a settings to turn this off System and Tenant Level. I understand your thought process. but its actually more of a burden to explain this to users then its worth. eventually we will use it, until then let the users get used to it. its been a burden on you also explain to your users why are you making this a priority.

 

4 hours ago, Vodia PBX said:

Other topics are more tricky. For example, we have added many features for LAN provisioning that look outdated today. Should we silently drop them? Or set the defaults so that the LAN deployment becomes the one that requires extra work? We have started to add some hints like changing ports but not actually doing it. Should we by default set he "IP routing list" to "private public"?

I presonally dont do onprem deployment, but i can tell you this. Mine is acting weird, i dont even understand it. last week i saw it. The pbx is in the cloud on vultr. this is what my LAN Devices page looks like: 

 

execpt for the last item that is not shown here.  it shows a poly phone that is already provisioned to a tenant extension and is in use. and instead of the Setup Button, it a button that says ext#@tenantDomainName.com. i dont know why its listed here.

 

I wil give you an explain of what happened to me yesterday. I am at my office, provisioning two VVX 450 for a exisiting client, I added the phone to poly ZTP, setup the profile to point to the correct server, booted up the phones, it did its ussual thing, upgrade to a firmware i am comfortable with, then sent the provioning request to the PBX, provisioned it, and all the registration are DEAD. nothing worth, but i know it got provisioned. after reseting them, manually provisioning the phones via web gui, still nothing. spent 20 min on this. then I check the blocked IP address, my IP that i was on was blocked. well the web gui was working, but it got blocked, a simple check to display an error like your IP is blacklisted in some Status page, would be made me aware of this. I simple deleted the blacklist and then it worked.

 

Improving just he logs would be great. having a filter where i can filter out these message, In my case, i would of looked for any log inside that tenant, that was coming from X IP address,  and was for device provisioning or SIP message was for registration.

 

4 hours ago, Vodia PBX said:

We had a lot of problems with admins using the same DNS address for the whole server as for one of the tenants, and hopefully have that sorted out in the latest builds. 

thats a good exmaple where a Config Status Page would display a warning. Like you said the system wont do it for you, since that a risk of breaking something. But display the most common ones.

• Current IP is blocked.
• A IP that is accepting connections also been blocked on a certain port. (meaning that IP is for sure for a tenant, but one phone is sending wrong credentials)
• Tenant does not have a valid domain name
• Tenants domain name is not resolvable
• Tenant domain name doesnt have a Valid SSL cert
• System UDP port is blank but tenant has UDP has SIP transport
• Tenant and its users doesnt have a default ANI. 
• i dont know what other commons erros happen

[Vodia PBX]

1 hour ago, mskenderian said:

I dont want to educate my users with passkeys, let the every app do that, when i see its mainstream I will just enforce it, until then please have a settings to turn this off System and Tenant Level. I understand your thought process. but its actually more of a burden to explain this to users then its worth. eventually we will use it, until then let the users get used to it. its been a burden on you also explain to your users why are you making this a priority.

The next build has a flag on the welcome page where they can decide to suppress the passkey topic until they explicitly enable it again. This should really keep annoyance to a minimum.

1 hour ago, mskenderian said:

I presonally dont do onprem deployment, but i can tell you this. Mine is acting weird, i dont even understand it. last week i saw it. The pbx is in the cloud on vultr. this is what my LAN Devices page looks like: 

We recently see that a lot. It's because scanners are jumping on anything that looks like it would provision Yealink phones and hand out a password. You can disable it with the setting "Automatically list unassigned MAC addresses" in the "Phone Settings", and that would be another setting that should be off by default when deploying a hosted PBX (it makes mostly sense in LAN deployments). We had previous attacks where the scanner went through the whole MAC address range of the Yealink phones. This is why the list is limited to max 256 devices. The fact that the phone is listed there does not mean that the PBX sends anything useful to the scanner.

1 hour ago, mskenderian said:

I wil give you an explain of what happened to me yesterday. I am at my office, provisioning two VVX 450 for a exisiting client, I added the phone to poly ZTP, setup the profile to point to the correct server, booted up the phones, it did its ussual thing, upgrade to a firmware i am comfortable with, then sent the provioning request to the PBX, provisioned it, and all the registration are DEAD. nothing worth, but i know it got provisioned. after reseting them, manually provisioning the phones via web gui, still nothing. spent 20 min on this. then I check the blocked IP address, my IP that i was on was blocked. well the web gui was working, but it got blocked, a simple check to display an error like your IP is blacklisted in some Status page, would be made me aware of this. I simple deleted the blacklist and then it worked.

Well its another classic... I know it happens to me as well again and again until I realized that my IP address was blocked. What else should the PBX do? Show a message "you are on a blocked IP address"? In what language? The PBX obviously wants to keep real attackers away from the PBX and essentially pretend to be dead, or at least provide as little information to a potentially hostile client. At this point, experience will turn those 20 minutes into maybe 20 seconds...