ping -c 4 8.8.8.8<\/pre>\n\n\n\nYour output should show something like<\/p>\n\n\n\n
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.\n64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=1.68 ms\n64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=1.70 ms\n64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=1.71 ms\n64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=1.69 ms\n\n--- 8.8.8.8 ping statistics ---\n4 packets transmitted, 4 received, 0% packet loss, time 3005ms\nrtt min\/avg\/max\/mdev = 1.686\/1.699\/1.718\/0.051 ms\n<\/pre>\n\n\n\nIf the server is unable to reach the destination, there may be a problem with your configuration. Follow the steps described here in order to troubleshoot the most common network issues with Linux Cloud Servers.<\/p>\n\n\n\n
\nTry UpCloud for free!<\/a><\/div>\n<\/div>\n\n\n\nCheck your network configuration<\/h2>\n\n\n\n
Make sure the network interfaces such as eth0 are enabled. To see all the configured interfaces, use this command.<\/p>\n\n\n\n
ip addr<\/pre>\n\n\n\nThe output of the command will show the status of each network interface on the server with \u201cstate UP\u201d or \u201cstate DOWN\u201d, for example as below.<\/p>\n\n\n\n
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<\/pre>\n\n\n\nTurn on any disabled interfaces with the next command.<\/p>\n\n\n\n
sudo ifup <interface name><\/pre>\n\n\n\nHere the interface name is one of the names listed in the ip addr<\/tt> command output like eth0<\/tt>, eth1<\/tt> or eth2<\/tt>.<\/p>\n\n\n\n
When all network interfaces have been enabled, try using the ping<\/tt> command again. If the problem persists, check that the network interfaces have IPs assigned to them, and they match the information in Network section<\/a> of the UpCloud control panel.<\/p>\n\n\n\n
Try restarting any problematic interface with the following commands.<\/p>\n\n\n\n
sudo ifdown <interface name>\nsudo ifup <interface name><\/pre>\n\n\n\nIf either of these commands fails, it is possible that the interface is in a state unknown to the command script. Try the same commands again with --force<\/tt> parameter to resolve any such issues.<\/p>\n\n\n\n
sudo ifdown --force <interface name>\nsudo ifup <interface name><\/pre>\n\n\n\nIf restarting the network interface fixed the issue, great! If not, continue with the troubleshooting.<\/p>\n\n\n\n
Check the network configuration file<\/h2>\n\n\n\n
Linux commonly stores network settings in specific files and reads them for example at boot or when using the ifup<\/tt> command. To make changes to the network configuration, you\u2019ll need to open the right file in a text editor. In Debian and Ubuntu-based distributions this can be done with<\/p>\n\n\n\n
sudo nano \/etc\/network\/interfaces<\/pre>\n\n\n\nIn most cases, the interfaces<\/tt> file should list at least the following interfaces.<\/p>\n\n\n\n
auto lo\niface lo inet loopback\n\nauto eth0\niface eth0 inet dhcp\n\nauto eth1\niface eth1 inet dhcp<\/pre>\n\n\n\nIn CentOS and other Red Hat variants, these configurations are split into separate files for each network interface and stored in \/etc\/sysconfig\/network-scripts\/<\/tt>. The default interface for internet connection is usually called eth0<\/tt>, opens the corresponding configuration file.<\/p>\n\n\n\n
sudo vi \/etc\/sysconfig\/network-scripts\/ifcfg-eth0<\/pre>\n\n\n\nThe configuration file for eth0 should look like this.<\/p>\n\n\n\n
DEVICE=eth0\nBOOTPROTO=dhcp\nONBOOT=yes<\/pre>\n\n\n\nIf the interfaces configuration files do not match the example here, edit the file specific to your system to restore the original functionality. For any changes made to these files to take effect, you must restart the interfaces to which the changes apply as described previously with ifdown<\/tt> and ifup<\/tt> commands.<\/p>\n\n\n\n
Check the server’s DNS records<\/h2>\n\n\n\n
When ping<\/tt> with an IP works, but the regular connection still fails, try pinging a domain name instead. For example, you can ping the UpCloud domain with like so.<\/p>\n\n\n\n
ping upcloud.com<\/pre>\n\n\n\nIf the domain does not reply, the problem is most likely with the way your server resolves domain names to IP addresses. Check your server\u2019s DNS records.<\/p>\n\n\n\n
sudo cat \/etc\/resolv.conf<\/pre>\n\n\n\nThe list should contain a minimum of 1 name server. All default DNS resolvers at UpCloud have the same IP addresses regardless of the availability zone. The DNS servers are provided automatically by the DHCP protocol and there should be no need for manual configurations in the operating system.<\/p>\n\n\n\n
The UpCloud DNS resolver IPv4 addresses are:<\/p>\n\n\n\n
\n
- 94.237.127.9<\/strong><\/li>\n\n\n\n
- 94.237.40.9<\/strong><\/li>\n<\/ul>\n\n\n\n
If your server has a public IPv6 address, you can also use IPv6 with the following servers:<\/p>\n\n\n\n
\n
- 2a04:3540:53::1<\/strong><\/li>\n\n\n\n
- 2a04:3544:53::1<\/strong><\/li>\n<\/ul>\n\n\n\n
If the list is empty do not edit it manually, because if you have a nameserver manager installed any changes you make will just get reverted. Instead, on Ubuntu and some Debian systems, you can try to update it with this command.<\/p>\n\n\n\n
sudo resolvconf -u<\/pre>\n\n\n\nOn Debian servers, which do not have resolvconf<\/tt> installed, you can edit the resolv.conf<\/tt> file directly.<\/p>\n\n\n\n
sudo nano \/etc\/resolv.conf<\/pre>\n\n\n\nAdd the lines shown below to the file, save and exit.<\/p>\n\n\n\n
nameserver 94.237.127.9\nnameserver 94.237.40.9<\/pre>\n\n\n\nFor those with resolvconf<\/tt> installed, in case resolv.conf is still empty after the update command, you can add nameservers to your interfaces file. Open it for editing.<\/p>\n\n\n\n
sudo nano \/etc\/network\/interfaces<\/pre>\n\n\n\nAdd a name server to the end of the eth0 section.<\/p>\n\n\n\n
auto eth0\niface eth0 inet dhcp\ndns-nameservers 94.237.127.9<\/pre>\n\n\n\nAfterwards, save the file and exit. You will also need to restart the network service with the following command.<\/p>\n\n\n\n
sudo service networking restart<\/pre>\n\n\n\nIn CentOS and other Red Hat variants the resolv.conf<\/tt> file is populated a little differently, if the file is empty, you can add up to two DNS entries in your network configuration file for the network interface responsible for the public IP. For example, open ifcfg-eth0<\/tt> it with the next command.<\/p>\n\n\n\n
sudo vi \/etc\/sysconfig\/network-scripts\/ifcfg-eth0<\/pre>\n\n\n\nEdit the file to look like this.<\/p>\n\n\n\n
DEVICE=eth0\nBOOTPROTO=dhcp\nONBOOT=yes\nDNS1=94.237.127.9\nDNS2=94.237.40.9<\/pre>\n\n\n\nExit the editor and restart the interface which the configuration file you just edited using ifdown<\/tt> and ifup<\/tt> commands.<\/p>\n\n\n\n
Test the connection both ways<\/h2>\n\n\n\n
Try pinging your server over the internet. Open a terminal or command prompt on your own computer and try pinging your server\u2019s public IP, which you can find in the UpCloud control panel under the Network section<\/a>.<\/p>\n\n\n\n
On your own computer: ping <server public IP><\/pre>\n\n\n\nTest the internet connection by pinging another site from your server, for example, use the following command to ping Google\u2019s public DNS.<\/p>\n\n\n\n
ping 8.8.8.8<\/pre>\n\n\n\nIf you have a second server deployed on your account and the problem is with the interface assigned with the private IP address, try to ping your other server, to and from it, using the private IPs listed in the UpCloud control panel.<\/p>\n\n\n\n
Should ping fail to receive a reply, try restarting all of your server\u2019s network services. In Debian and Ubuntu 12.04 or older, use the command below.<\/p>\n\n\n\n
sudo service networking restart<\/pre>\n\n\n\nOn CentOS and other Red Hat-based systems, restart the network with the command underneath instead.<\/p>\n\n\n\n
sudo service network restart<\/pre>\n\n\n\nIn Ubuntu 14.04 and newer you\u2019ll need to run the command for each network interface separately, for example, you can restart eth0 simply with the following.<\/p>\n\n\n\n
sudo ifdown eth0 && sudo ifup eth0<\/pre>\n\n\n\nAfter restarting the network services, try running ping again both ways. If ping works in one direction but not in the other, check your firewall settings.<\/p>\n\n\n\n
Find out where the connection fails<\/h2>\n\n\n\n
Your internet connection in its basic form boils down to knowing the route to take to your destination. It is sometimes possible for the connection routing to hit a dead end, which then results in a failed connection. Run a route trace from your server to see at which network node the connection gets lost.<\/p>\n\n\n\n
Ubuntu servers have a networking tool called mtr<\/tt> for this purpose, start it with the following command.<\/p>\n\n\n\n
mtr 8.8.8.8<\/pre>\n\n\n\nAnd to quit just press q<\/tt> on your keyboard.<\/p>\n\n\n\n
To do this on Debian systems where mtr<\/tt> is usually not installed by default, you can use traceroute<\/tt> instead.<\/p>\n\n\n\n
traceroute -4 8.8.8.8<\/pre>\n\n\n\nOn CentOS servers use tracepath<\/tt> command.<\/p>\n\n\n\n
tracepath 8.8.8.8<\/pre>\n\n\n\nDifferent distributions run different tools and the output of these tools also differs slightly. The mtr<\/tt> runs in the foreground until cancelled, updating the response table on each pass, example output is shown below.<\/p>\n\n\n\n
My traceroute [v0.85]\nubuntu.jr-ux.com (0.0.0.0) Wed Jul 29 16:03:43 2015\nKeys: Help Display mode Restart statistics Order of fields quit\n Packets Pings\n Host Loss% Snt Last Avg Best Wrst StDev\n 1. 83.136.252.2 0.0% 8 0.5 0.4 0.4 0.5 0.0\n 2. te0-0-1-2.rcr11.lon10.atlas.cogentco.c 0.0% 8 0.8 0.8 0.7 1.1 0.0\n 3. te0-7-0-13.ccr22.lon01.atlas.cogentco. 0.0% 8 1.2 1.2 1.1 1.3 0.0\n 4. 149.14.8.150 0.0% 8 1.3 2.7 1.1 13.0 4.1\n 5. 216.239.47.25 0.0% 7 1.9 1.8 1.8 1.9 0.0\n 6. 216.239.47.59 0.0% 7 1.8 1.9 1.8 2.0 0.0\n 7. google-public-dns-a.google.com 0.0% 7 2.0 2.1 1.9 2.3 0.0\n<\/pre>\n\n\n\nTraceroute<\/tt> and tracepath<\/tt> are very similar to one another, they run pass over the network to the given destination and show the latency to each node that replied. The example of the traceroute shown underneath has much of the same information as mtr<\/tt>.<\/p>\n\n\n\n
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets\n 1 83.136.252.2 (83.136.252.2) 0.494 ms 1.010 ms 1.006 ms\n 2 te0-0-1-2.rcr11.lon10.atlas.cogentco.com (149.11.22.93) 0.877 ms 1.415 ms 1.413 ms\n 3 te0-7-0-13.ccr22.lon01.atlas.cogentco.com (154.54.75.65) 1.107 ms 1.643 ms 1.648 ms\n 4 149.14.8.150 (149.14.8.150) 1.499 ms 1.495 ms 1.492 ms\n 5 216.239.47.25 (216.239.47.25) 2.096 ms 64.233.174.213 (64.233.174.213) 2.097 ms 216.239.47.23 (216.239.47.23) 2.090 ms\n 6 72.14.237.41 (72.14.237.41) 2.088 ms 216.239.47.59 (216.239.47.59) 1.717 ms 209.85.249.241 (209.85.249.241) 1.995 ms\n 7 google-public-dns-a.google.com (8.8.8.8) 1.733 ms 2.250 ms 1.721 ms\n<\/pre>\n\n\n\nTry the same from your own computer to the server using one of the tools mentioned above, for example, using the command below.<\/p>\n\n\n\n
traceroute -4 <server public IP><\/pre>\n\n\n\nIf an outbound trace does not reach even the first node, check your network settings and firewall. The firewall may also be responsible for connection rejections if the trace over the internet to your server falls short just before reaching the server.<\/p>\n\n\n\n
Firewall settings<\/h2>\n\n\n\n
Check that your connection is not getting blocked by a firewall. CentOS and some other Red Hat-based distributions have strict firewall rules by default. The following command will list all server-side firewall rules on your system.<\/p>\n\n\n\n
sudo iptables -L<\/pre>\n\n\n\nIptables is the Linux built-in software firewall, and the command above prints out the following.<\/p>\n\n\n\n
Chain INPUT (policy ACCEPT)\ntarget prot opt source destination\nACCEPT all -- anywhere anywhere the RELATED,ESTABLISHED\nACCEPT tcp -- anywhere anywhere The firewall dpt:http\nACCEPT tcp -- anywhere anywhere tcp dpt:ssh\nDROP all -- anywhere anywhere\n\nChain FORWARD (policy ACCEPT)\ntarget prot opt source destination\n\nChain OUTPUT (policy ACCEPT)\ntarget prot opt source destination<\/pre>\n\n\n\nThis is an example of a simple firewall table. It has rules to allow SSH and HTTP traffic, but block all other input, which also blocks ping attempts. Check your server\u2019s iptable<\/tt> for any is shown that might block your connection.<\/p>\n\n\n\n
![\"Database](\"https:\/\/upcloud.com\/media\/database-firewall-settings.png\")
<\/figure>\n\n\n\n