Troubleshooting Vultr Network Connections

Vultr Firewall Operating Systems Network Troubleshooting

Published on April 13, 2020•Updated on November 21, 2023

Troubleshooting Vultr Network Connections header image

If you are having trouble connecting to your server application, this guide has the tools you'll need to diagnose issues with your firewall, application, name servers, and connectivity.

Vultr Standard Port Blocking

We block several outbound ports for network security. Please review the Standard Port Blocking topic.

Vultr Firewall

Server instances at Vultr may be protected by the Vultr firewall, an OS firewall, or both simultaneously. Make sure the Vultr Firewall is configured properly. For debugging purposes, if your server instance is linked to a Vultr Firewall group, try removing it from the group temporarily. See the Vultr Firewall quickstart guide for an overview.

Web console SSH

If you are blocked from SSH, use the noVNC console in your customer portal at https://my.vultr.com/.

Click on your server instance.
Click the "View Console" icon.
The noVNC console will open.

See our complete Web Console FAQ.

OS Firewalls

Vultr's standard OS image have firewalls enabled by default that block a great deal of traffic. If you are having trouble connecting to your server applications, verify your firewall configuration.

CentOS

If you installed a Vultr CentOS image, firewalld is enabled by default, and blocks a great deal of traffic. If you are having trouble connecting to your server applications, verify your firewalld configuration.

If you installed from your own ISO, the default firewall installation varies between versions. These are the most common configurations, your specific server may have a different firewall installed.

CentOS 6 - See the iptables quickstart guide.
CentOS 7 - See the firewalld quickstart guide.
CentOS 8 - See the nftables quickstart guide.

CoreOS

CoreOS has no default firewall. The most popular choice for an OS-level firewall is iptables. See the iptables quickstart guide.

Debian

Debian 9 and 10 may use one of several firewalls. If you installed a Vultr Debian image, UFW is enabled by default.

See the iptables quickstart guide.
See the nftables quickstart guide.
See the UFW quickstart guide.

Fedora

If you installed a Vultr Fedora image, firewalld is enabled by default.

Fedora, all versions, see the firewalld quickstart guide.

FreeBSD

If you installed a Vultr FreeBSD image, pf is enabled by default. IPFW and IPFILTER are also available.

See the pf quickstart guide.
See the IPFW quickstart guide.
See the IPFILTER quickstart guide.

OpenBSD

If you installed a Vultr OpenBSD image, pf is enabled by default.

See the pf quickstart guide.

Ubuntu

If you installed a Vultr Ubuntu image, UFW is enabled by default.

See the UFW quickstart guide.

Windows

The Windows Firewall is enabled by default on Vultr's Windows image. See the Windows Firewall quickstart guide.

More Diagnostic Steps

If you have determined that your traffic isn't blocked by either a Vultr Firewall or an OS-level firewall, try some additional debugging steps.

Is the server alive?

ping

ping is a basic debugging step to verify a server is available by sending an ICMP packet and receiving a reply.

It's possible to configure a machine to ignore ping. A ping failure doesn't prove the server is down, but a ping success does verify the server is available. This example pings 192.0.2.22 four times (using the -c 4 option), then stops and prints statistics.

# ping -c 4 192.0.2.22
PING 192.0.2.22 (192.0.2.22) 56(84) bytes of data.
64 bytes from 192.0.2.22: icmp_seq=1 ttl=54 time=15.4 ms
64 bytes from 192.0.2.22: icmp_seq=2 ttl=54 time=15.3 ms
64 bytes from 192.0.2.22: icmp_seq=3 ttl=54 time=15.4 ms
64 bytes from 192.0.2.22: icmp_seq=4 ttl=54 time=15.4 ms

--- 192.0.2.22 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 15.340/15.377/15.424/0.030 ms

For advanced options, use ping -h.

Is the application is listening on the correct port?

netstat

netstat (Network Statistics) is useful to query the state of your network connections. It is available for Linux, Windows and MacOS. See our netstat troubleshooting guide to check your application.

nmap

Try scanning the server with nmap, which is available for all Linux systems via their respective package managers. Windows users can download namp from the official site, which also has a version for MacOS.

Use the Vultr nmap troubleshooting guide for information on scanning your server.

Does the server name match the expected IP address?

nslookup

nslookup is used to query internet domain name servers. This is useful to verify your servers name properly resolves to the expected IP address.

Verify the IP address of example.com using the internal name resolver.

# nslookup example.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Name:   example.com
Address: 2606:2800:220:1:248:1893:25c8:1946

Verify the IP address of example.com using Google's public DNS (8.8.8.8).

# nslookup example.com 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34
Name:   example.com
Address: 2606:2800:220:1:248:1893:25c8:1946

Compare both examples to verify the server resolves the same IP address for example.com as a public name server.

For advanced options, see the nslookup help with man nslookup.

dig

Many Linux systems have replaced nslookup with dig, the Domain Internet Groper. dig also queries domain name servers, but provides more information than nslookup.

Example:

# dig example.com

; <<>> DiG 9.11.5-P4-5.1ubuntu2.1-Ubuntu <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55898
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            6521    IN      A       93.184.216.34

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Apr 01 20:07:19 UTC 2020
;; MSG SIZE  rcvd: 56

For advanced options, see the dig help with dig -h.

MTR Reports

After completing these debugging steps, you may still have questions. Please generate an MTR network report in both directions and then open a support ticket. We are happy to assist you.