SOLVED Incredible PBX 2020 Public Not Currently Working?

[infiniti]

Hi, everyone. I've been using IPBX for years over the many versions and would like to thank the community for this awesome piece of technology that's always come together so well.
I've been trying to get the Incredible PBX 2020 Public version as shown here http://nerdvittles.com/?p=31290 and the follow up guide to make it public here http://nerdvittles.com/?p=31488 installed and running

I can get Incredible PBX 2020 running 100% from the 1st guide but following the 2nd guide & trying to make it public it always gives errors which result in the server not being able to connect to or ping any IP, but I can still SSH in from my own IP that was initially added in the iptables.
I've tried over half a dozen times on 2 diff VPS providers with the FQDN I already have setup to forward to the server's IP and set the hostname up properly in Centos 7 / etc / hosts / but they all result in the same errors and issues.

Someone please help me get this going or confirm trying to make IPBX 2020 to be Public is currently broken from the recent guide..

Log Paste of SSH output showing errors:

2020-03-21 20:30:00 (79.3 MB/s) - 'iptables-custom-public.tar.gz' saved [1925/19 - Pastebin.com

Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

pastebin.com

Thank you to anyone that can offer any help / input on this

 

[tbrummell]

ICMP (ping) is blocked by the PUBLIC setup, you can comment out this line:

#-A PREROUTING -p icmp -j DROP

in /etc/sysconfig/iptables and issue an iptables-restart to get ping back.

You say it doesn't work, did you actually try and register a phone via the FQDN you set up? You'll notice some other IP blocks that are dropped in that file as well. If you are like me and have a VPN link to your server, it's quite possible your local IP space is being dropped there as well. But from the PUBLIC Internet, anything should register just fine via FQDN. What about trunks, did you get a trunk to register with your provider?

 

[tbrummell]

Ahhh, I looked at your pastebin again, I see your errors. Maybe Ward's server was having issues at the time, but I can download that file that failed just fine.

 

[infiniti]

Much thanks for your input on this, unfortunately it wasn't Ward's server having issues at that time this is a repeatable thing I've done over 15 reinstalls trying diff things (enab

 

[tbrummell]

It says SOLVED, is this solved?

And what command are you using to trigger the public install?

 

[tbrummell]

After the iptables restart it looks like it all goes to hell. Which VPS' have you used? I've deployed PUBLIC on Vultr and Digital Ocean only.

 

[infiniti]

No it's not solved and I tested on other VPS providers such as Hetzner which is KVM based and had no issues. And of course on a dedicated server the 2020 public patch had no issues after installing.

But on VPSDime which uses OpenVZ 7 for its VPS's this issue still happens, so I suspect maybe all OpenVZ 7 based VPS's have this issue?
I've used VPSDime for years and its never had an issue on any installing any of IPBX releases.

I really like this provider and would not mind posting more logs, giving full credentials to access the VPS for anyone willing to take a look, or reinstalling another dozen times if it means getting public 2020 patch to work for myself and anyone else needing to use a VPS provider like this.

That being said I am happy to have this working on another VPS provider for now.

Thank you tbrummell for your help on this and anyone else that wants to chip in!

 

[infiniti]

tbrummell the VPS providers you mentioned when I checked looks like they are all KVM based too like the Hetzner provider that worked for me.

Side note, I also tried disabling TAP/TUN and reinstalling on the VPSDime VPS but no luck

 

[tbrummell]

OHHHHHH, I believe it has to be KVM based as ipset? is used, which I believe OpenVZ doesn't support. Or it needs to be a super new kernel to support ipset, something like that. I'm sure @wardmundy can speak more to the requirements.

 

[infiniti]

Hm, an interesting development...
I followed up with support of the VPSDime provider to ask then to enable ipset on the container for the node and they said they checked and it was already enabled and working:

root@ipbx00:/ $ ipset create test nethash
root@ipbx00:/ $ ipset add test 1.2.3.4/32
root@ipbx00:/ $ iptables -A INPUT -m set --match-set test src -j DROP

 

[tbrummell]

You're outside of my pay grade at this point, but the install script certainly doesn't like something when running on OpenVZ, that's for sure.

If you have the time, try and execute each step of the script manually and see exactly where it barfs, might help pinpoint why.

 

[wardmundy]

Our tests with latest OpenVZ containers proved IPset does not work reliably. Sorry.

 

[infiniti]

Our tests with latest OpenVZ containers proved IPset does not work reliably. Sorry.

Okay good to know, thanks for confirming this on that side