Vitxi WebRTC Registration errors - persistent issues

We are seeing many Vitxi WebRTC registration errors.
We have verified our URL is whitelisted in any traffic shaping. But the issue happens at many locations.

What should be looking for to troubleshoot?

image

What happens when you click on that port 8089 link?

Check the certificate authority and also verify to add http daemon to firewall rule to accept the connection

This issue may be associated with the validity of your certificate, also you must add the rule " Asterisk HTTP Daemon ." at Admin > Firewall > Rules.

Clicking on the port 8089 link does nothing. Not found/404/inaccessible with both http and https with :8089 at end of URL. phones.charter.academy:8089

The Asterisk HTTP Daemon is allowed already. Though, it is the last on the list. Not sure that matters?
image

The cert states it is valid. But is there something else in there that might be off.
image

@JO_CPA,

Have you enabled the Mini HTTP Server?

If you have an additional firewall in front of the PBX server, you have to enable all the required ports in that firewall as well.

phones.charter.academy - 164.90.159.226
image

Yes, Mini HTTP Server is and has been enabled. Are those ports and TLS OK?
image

Also, here are results of port scan from other location to VPBX server
image

Port 8089 must be enabled over TCP.

If everything is well configured, and the required ports are open, you should be able to access “https://phones.charter.academy:8089/ws” and get the result below.

MiniHTTPServerResult

Additionally, accessing “https://phones.charter.academy:8089/httpstatus” must show the following result.

MiniHTTPServerHTTPStatus

Hello,

Thanks for this info! I ran the following commands to open up the TCP ports:
sudo iptables -A INPUT -p tcp --dport 8089 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 8089 -j ACCEPT

It resulted in these entries showing up when I run sudo iptables -L (same rule is in OUTPUT)

in_iptables

However, I’m still not able to connect through TCP. I get an ERR_EMPTY_RESPONSE HTTP error. When I run the systemctl command to list services, now I see the iptables service is inactive/dead.

When I run linux commands to check the status, this is displayed: Unknown operation 'iptables'.
Even though the main iptables file isn’t in the directory, I was able to look at the iptables-config contents . Since save on restart isn’t on, I’m thinking iptables will correct itself with a reboot, but I can’t reboot until the end of the day unfortunately.

Can anyone provide any information as to what I did wrong, and how to do it correctly when iptables reloads, and if it will indeed reload? My hunch is the -j flag on the initial commands put the service is a corrupt state, but I’m kind of in the dark here. All and any help is greatly appreciated!!! I can provide as much info as needed to get this solved as efficiently as possible. I had to remove a few photos because of the forum rules for new users, but I can post them if they help troubleshooting.

Thanks again,
Andrew

The firewall is already taking care of the IP tables. Did you allow the HTTP Daemon?

Is there another firewall between the client and server?

You should be able now to post more photos.

1 Like

Here are our rules, VPBX - Firewall
Asterisk HTTP Daemon is allowed… and has been.

image

@JO_CPA,

Where is this server hosted?

Make sure there’s not an additional firewall between the Server and the clients.

It is a Digital Ocean marketplace droplet originally.
No firewall on the droplet. Just what the CentOS/VPBX has configured.

image

Do you have any other servers on that DO network? If so, setup a Socks Proxy to the second server, and try to connect to the local IP of the PBX, that would indicate if there’s anything blocking externally.

DO and many other VPS providers are known to block uncommon ports if they detect “abuse”

I appreciate all the help! My team and I were working on this yesterday and I wanted to share our findings and ask some questions.

  • Our server is part of a private network, that involve both a public and private IP for each device on the network. I am able to see the webpages for both ws and httpstatus but it is strange because at the end of the day, I didn’t do any updates to the system. I restored the DO droplet because what I tried yesterday messed up the linux services to the point our system wasn’t functioning. At this point, I’m not sure why I can see the webpage and wondering if the bind addresses need to sync with the public/private IPs? Here’s the httpstatus webpage:
    image

My main question is, do the below firewall rules need source and dest populated with public and/or private IPs?
image

  • Second question: I have a hunch the DO marketplace droplet, and the fact it’s part of a private network, is causing some unexpected firewall/networking issues. Does VitalPBX use the linux services firewalld, iptables, or both? It seems like there’s a conflict between the two, and I’m not sure what’s the correct configuration, from a linux service(s) standpoint. I can provide a screenshot if needed.

Thanks so much! I really do appreciate all the info and learning about the VitalPBX system!
Andrew

And we are back to 404 on httpstatus page. It keeps changing… working/not working. I’ve confirmed that this happens on any/all connections (managed/unmanaged)

Also, I was just checking the Network section in VPBX. Does this have anything to do with it?
image

As this is an urgent issue causing a major disruption to phone service, we would like to use paid support to get this addressed. Another team member is reaching out.

Vital/Vitxi Staff,

We have submitted a ‘paid support’ request, to get this resolved today.
Please reference Ticket ID: #563

We asked for a meeting today at 8 A.M (PDT), but we didn’t receive confirmation.

Hi Miguel,
Yes, thank you… I addressed that within the ticket.
In response, yes today at 2pm PDT would be great… if my colleagues agree.
I’ll respond within the ticket.