Digital Ocean VS Vultr

(Greg Snover) #1

Ok - It came up here: Current Experience - Hyper-V FreePBX on Azure - General Help - FreePBX Community Forums so I created a free account on both Vultr and Digital Ocean - they seem very similar to me so far - $50.00 credit on Vultr versus a $100 credit on Digital Ocean that has to be used in the first 60 days - if I choose DO, using that up in that time will not be a problem.

Specifically from the other thread about Vultur:

Personally a couple of years ago, Vultr dropped everyone of my Los Angeles servers for hours at a time, they never fessed up or compensated even with un-surmountable evidence. ( I never forgave them, DO gets my business right now)

That is exactly what I am trying to avoid!

But Digital Ocean only has two US Datacenters - New York and San Francisco (I guess you could count Toronto also…) and although each of those locations show 3 “slots”, only 2 are available in NY and only one is available in SF - so lets say I have 50 customers, and I spread them over all three North American Locations - that means 4 data centers, so 12.5 customers per center - not bad.

Also, I am in the middle of Fly-Over Country (New Mexico) so physically, they are all pretty distant from me.

Contrast that with Vultr - If I also include Toronto for them, there are 9 locations in North America for them - that would be 5.5 customers per location.

If I knock Vultr down to just the centers close to me (Dallas, LA, Silicon Valley and Chicago) I still achieve the same dispersal as Digital Ocean but with centers that are closer (=lower ping) to the market I am serving - especially Dallas.

So I think this is a Plus for Vultr.

Vultr also lets me easily set the reverse DNS for my Public IP - DO might be able to do it, but I haven’t found it yet - it’s a little thing, but every little bit counts.

Digital Ocean has the ability to deploy a FreePBX courtesy of Bill Simon. But it’s out of date (can be updated pretty quickly) and it has a weird networking configuration (2 NICS, first NIC with a Public and a Private IP, second NIC with another Private IP and IPV6 enabled on both NICS). The networking was an easy fix also, but Vultr has an actual (recent) ISO of FreePBX to be deployed, so again Vultr comes out better here.

I think what I am really looking for is overall reliability of the solution - things ALWAYS go wrong, but if the incidence is minimized and quickly resolved, it is usually tolerable.

DO was formed in 2011 - Vultr was formed in 2014, so they both have been around for a while.

The pricing seems very similar - especially for what I am doing.

So that is really my question - Neither company is forthcoming with any total uptime statistics (5-9’s would be awesome, but I doubt either company achieves that) so I will have to rely on experiences from other FreePBX’ers.

What has been your experience?

(Tom Ray) #2

I have had Vultr for about 6 years now. There has been maybe two major outages where I had stuff down for a couple hours. Outside of that, I’ve had zero problems with Vultr. Of course, I’ve been fluxing from high $800-$1000+ a month depending. So perhaps my experience is different than someone spending $20 for 4-5 servers a month.

(Tom Ray) #3

Also there is this: and yes, I’ve always gotten credits based on the SLA.


No experience on DO. Been running my own PBX on Vultr since Nov. 2019. There have been two tickets. Relevant excerpts:

2020-07-21 22:06:34 This server had no useful communication today July 21, 2020 from approximately 14:28:05 through 14:33:37 UTC. However, during this time there were ARP and ICMP Network Unreachable packets received, so I’m pretty sure that the server was being scheduled and the network stack was working. Are you aware of any network trouble at the time?

2020-07-22 01:35:08 Thanks for your patience. After further investigation, we identified a software bug within our edge infrastructure that caused an outage across our SJC Network around the time you reported. We have been working extensively with our Vendor Support in efforts of resolving the issue permanently.

2021-05-27 05:11:51 Are you aware of an issue with the node or network, or has my server crashed? If the latter, is it normal to show as unknown?

2021-05-27 05:13:25 Thank you for contacting support! We are currently investigating this. Please stand by for further updates and thank you for your continued patience.

(At 05:22:34 I noticed it was back up, but did not determine how long it had been down.)

2021-05-27 05:50:29 Our monitoring system has discovered an abusive neighboring instance in your host node’s shared resource environment which may have created intermittent issues for your VM. We have disabled the problematic instance, and performance has returned to an optimal state.

So, not quite five nines but adequate for my needs and very inexpensive.

(Tom Ray) #5

I will say this, in 2014/2015 I had DO and Linode then I got Vultr. I no longer have stuff on DO or Linode six years later.

(Jared Busch) #6

I started using Vultr in 2015. They were lower cost compared to DO.
I never left, because I have never had a severe enough problem.

The Chicago datacenter had a problem earlier this year, but it was not global. Some of my systems there were up some were unreachable.

All of them went down when they resolved it. SO I assume the issue was a large one that forced them to cycle something pretty major.

Various datacenters have gone down. Never their entire network.

But I’m not using Vultr for anything that needs 24/7 completely datacenter redundant uptime.

That would be a case for AWS/Azure and regional redundancy.

Here is another example of a failure from Vultr in Chicago. In that instance, only one system was affected. I have ~15 servers in the Chicago datacenter. a few in NJ, 4 in Atlanta, and 1 in Tokyo.


I find the whole network experience better at DO, PTR’s are automatically created based on your ‘droplet’s’ name, the firewall is basic but solid, the nameservice is free and comprehensive but 'you have to ‘bring your own domains’.

Best thing for me is their comprehensive API with a simple frontend with auto-completion whereby you can script everything from the creation of a machine from bare metal, to a scripted move of a ‘floating IP’ from one machine to another , resizing up or down of a machine’s cpu’s and memory in a few minutes. or moving a machine to Singapore.

Not quite Amazon or Google but a damn sight cheaper.

(I see vultr is trying to catch up here though)


I was using linode 3 years ago and their internet connection was stable but their servers were a little bit slow, i was very happy with their servers but i wanted something faster because of the recording report and other stuff, than i decided to try vultr which their servers were fast but their internet connection was not that good, i wanted to use vultr so i tried another server in europe but same issue the internet connection was having issue which is not good thing for voip. After that i looked for another cloud provider and i found UpCloud, they gave me $150 credit so i decided to try and their servers were as fast as vultr and never had issue with internet connection. Its being 1 year that i am using UpClooud and i am happy with them. I just wanted to share my experience. Thanks

(Lorne Gaetz) #9

Not performance related, but another mark against DO is that they consistently come near the top (or bottom!) of the list of SIP abusers as compiled by DO has been informed but no improvement:

(Defcomllc) #10

I just opened an account to test with Vultr using their New York (NJ) server and the $10 month server. Installed FreePBX using the “Upload your Own ISO” feature using the latest FreePBX Stable ISO for a test environment. This is my first hosted FreePBX install. All installed and running, configuring FreePBX via WEBGUI now.

How many of you enable and configure the Vltor firewall option? Or are you guys just using the FreePBX Firewall only for these hosted installs?

(Simon Telephonics) #11

My pleasure. Do:

yum -y update && fwconsole ma upgradeall && fwconsole r ## and bob's your uncle

which is the first thing anyone should do on any hosted install.

I’ll get the image refreshed though so that it’s more recent. Thanks for the note.

The networking choices are yours to make in the pre-launch configuration screen.


My personal sorted list of culprit by ASN’s against UDP/5060

    510  CN | apnic    | 2008-02-01 | CNNIC-TENCENT-NET-AP Shenzhen Tencent Computer Systems Company Limited, CN                                                                               
    369  US | arin     | 2012-09-25 | DIGITALOCEAN-ASN, US                                                                                                                                     
    161  US | arin     | 1998-11-13 | CENTURYLINK-US-LEGACY-QWEST, US                                                                                                                          
    136  CN | apnic    | 2002-08-01 | CHINANET-BACKBONE No.31,Jin-rong Street, CN                                                                                                              
    102  GB | ripencc  | 2005-06-06 | M247, GB                                                                                                                                                 
     92  CN | apnic    | 2001-09-17 | CHINA169-BACKBONE CHINA UNICOM China169 Backbone, CN
     81  CN | apnic    | 2012-03-13 | TENCENT-NET-AP-CN Tencent Building, Kejizhongyi Avenue, CN
     68  FR | ripencc  | 2001-02-15 | OVH, FR
     64  DE | ripencc  | 2010-06-11 | CONTABO, DE
     53  CN | apnic    | 1996-01-09 | CHINA169-BJ China Unicom Beijing Province Network, CN
     51  PS | ripencc  | 2000-05-22 | PALTEL-AS PALTEL Autonomous System, PS
     50  US | arin     | 1997-03-31 | MICROSOFT-CORP-MSN-AS-BLOCK, US
     45  KR | apnic    | 1996-04-22 | KIXS-AS-KR Korea Telecom, KR
     45  GB | ripencc  | 2014-06-04 | CDN77 (^_^)/, GB
     43  US | arin     | 2005-12-12 | AS-COLOCROSSING, US
     41  CN | apnic    | 1996-01-09 | CHINANET-SH-AP China Telecom (Group), CN
     40  VN | apnic    | 2009-08-28 | VNPT-AS-VN VNPT Corp, VN
     37  US | arin     | 2000-05-04 | AMAZON-02, US
     34  US | apnic    | 2015-02-16 | LINODE-AP Linode, LLC, US
     34  IN | apnic    | 2006-02-13 | AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services, IN
     33  TW | apnic    | 2002-08-01 | HINET Data Communication Business Group, TW
     32  US | arin     | 2000-03-30 | GOOGLE, US
     31  US | arin     | 2010-10-28 | PHMGMT-AS1, US
     31  US | arin     | 2004-12-17 | HIGHWINDS2, US
     31  IN | apnic    | 2009-01-29 | BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service, IN
     31  CN | apnic    | 2007-01-25 | BAIDU Beijing Baidu Netcom Science and Technology Co., Ltd., CN
     30  VN | apnic    | 2002-10-08 | VIETEL-AS-AP Viettel Group, VN
     29  US | arin     | 2008-10-16 | PERFORMIVE, US
     28  US | arin     | 2018-01-09 | DEDIPATH-LLC, US
     27  US | arin     | 2011-03-21 | ORACLE-BMC-31898, US
     26  US | arin     | 2009-10-22 | ASN-QUADRANET-GLOBAL, US
     26  US | arin     | 1996-05-16 | COGENT-174, US
     25  US | arin     | 2001-05-11 | AS-CHOOPA, US
     25  US | arin     | 1990-08-03 | UUNET, US 
     25  KR | apnic    | 1998-06-03 | SKB-AS SK Broadband Co Ltd, KR
     24  NL | ripencc  | 1996-11-13 | LIBERTYGLOBAL Liberty Global (formerly UPC Broadband Holding, aka AORTA), NL
     24  IR | ripencc  | 2008-07-17 | FARAHOOSH, IR
     23  ID | apnic    | 1998-01-06 | TELKOMNET-AS-AP PT Telekomunikasi Indonesia, ID
     22  RU | ripencc  | 2005-07-01 | ROSTELECOM-AS, RU
     22  CA | arin     | 2013-01-15 | IT7NET, CA
     21  US | arin     | 1997-02-14 | COMCAST-7922, US
     21  IN | apnic    | 2000-01-19 | BSNL-NIB National Internet Backbone, IN
     21  CN | apnic    | 2008-02-01 | CNNIC-ALIBABA-US-NET-AP Alibaba (US) Technology Co., Ltd., CN
     20  DE | ripencc  | 2002-06-03 | HETZNER-AS, DE
     20  CA | arin     | 1999-03-03 | BACOM, CA 

Yet another good reason to just not ‘do that’

(Greg Snover) #13

Yeah, that is exactly what I did - like I said no big deal just a heads up - it’s nice that it is there.

I must have missed them - I didn’t see anything I could change in the first setup, but I was flying blind - I will look again if I try them for another machine.

(Greg Snover) #14

This is something that I am going to really miss my SonicWALL’s for - Geo-IP Isolation - we never see any attacks against our PBX’s from anywhere other than the US - China, Russia, all the 'Stans, India and the Middle East are all blocked and they never even hit our machines - that will change when I am no longer behind them.


Stop listening to UDP/5060 for anything but the most recalcitrant VSP (vitelity ?) and broadly drop that at the DO/Vultr firewall add pin-holes where necessary. Same result, nothing to see.

(Greg Snover) #16

No, you (personally) convinced me of that years ago - the difference was astonishing - I would say better than 98% reduction in attempts - I really think FreePBX should default to something (anything) other than 5060/5061/5160/5161 but it’s easy enough to change.


If one doesn’t want to do that then perhaps deploy ipset as a filter in your firewall.

for the method, if ‘servers’ is a file with all your PBI in it and you have previously set up ‘ssh key auth’

for i in $(cat servers) ;do  ssh $i  "rasterisk -x  'sip show peers'";done|grep OK peers|cut -d ":" -f2|awk '{print $2}'|sort -n|uniq |tee  goodguys

gives you a basic source for a whitelist that will catches most DHCP changes (and trunks if they ‘qualify’) if you

nc 43 < goodguys|cut -d '|' -f3

which will expose the underlying networks in play which you can add to your ipset whitelist.

for a blacklist with the assumption that one bad apple in a basket often is a reason to believe all the apples in that basket might be bad also

echo -e "begin\nverbose"|tee badguys
curl -s|sed 's|/[0-9]*||'|grep '^[0-9]'|tee -a badguys
echo "end">> badguys

gives you a few more than 10686 ‘active culprits’ but lets expand the ‘catch’ with

netcat 43 < badguys|awk '{print $5}'|sort -n|uniq

and your at a more reasonable ipset of 3490 that catches ‘subnets’ but now includes 274,149,820 ‘erstwhile culprits’

No, it’s not foolproof but is what used to work for me before It dawned on me there is a much better solution.

(You could use the same method to expand the bans in newer versions of Fail2ban and remember that it is not just voip blacklists that should be considered)



IMO, blocking by ASN / country / bad guys is complex, nearly useless and often causes trouble. If your plane is unexpectedly diverted to Minsk, your call to say you’ll be late shouldn’t be blocked because Belarus is on the bay guy list.

There are two kinds of attackers, those who scan every IPv4 address on the internet looking for vulnerabilities, and those who are attacking your system specifically.

For the former, hiding behind a ‘secret’ domain name is simple, nearly 100% effective, while never blocking legitimate access.

Though a domain name filter is not very useful against a targeted attack, neither is any sort of blacklist – the attack will surely be launched from a non-blacklisted address in the destination country.

Defense against targeted attacks requires a real security mechanism (VPN, client certificates, etc.)

IMO, the only common service that can’t be protected with a domain name filter is SSH. However, I don’t see much risk in using a strict whitelist for that – if you lose control of a cloud system or a VM, console access allows recovery. For on-site bare metal, you can ask someone present to enable your access.


My solution post the ipset whitelist/blacklist thingy which so far seems rock-solid, is to only allow TLS connections for anything (but recalcitrant VSPs) , put all your services behind HAPROXY and only allow ‘strict SNI’ connections through, you will be totally invisible to anything that is not connecting through your various cert protected domain names, ip scans will not leak anything useful

This thread has gone off the reservation, I will now STFU here :wink:


(I wouldn’t personally use Belarusian SIM cards I don’t want to be sent to a gulag! but none of MTC, Velcom, life nor beCloud are on that list, FreePBX firewall access should likely be before ipset blacklist in your iptables chain perhaps ?)

Belarusion ASN on the list are

6697    |   |       | BY | ripencc  | 2012-03-30 | BELPAK-AS BELPAK, BY
6697    |    |       | BY | ripencc  | 2012-03-30 | BELPAK-AS BELPAK, BY
6697    |   |     | BY | ripencc  | 2003-10-01 | BELPAK-AS BELPAK, BY
50590   |     |       | BY | ripencc  | 2008-04-15 | NETBERRY-AS, BY
25106   |     |      | BY | ripencc  | 2011-11-03 | MTSBY-AS, BY
6697    |  |    | BY | ripencc  | 2009-12-10 | BELPAK-AS BELPAK, BY
6697    |   |      | BY | ripencc  | 2009-12-10 | BELPAK-AS BELPAK, BY