Question

Droplet has lost outbound connectivity

So, today unattended-upgraded asked me for a reboot. No big deal I thought, and rebooted.

After rebooting the droplet it can no longer connect to the internet, although i can connect to it from the internet. (e.g. via SSH or HTTP)

Here is what I tried so far (I’m going to obfuscate the last octet of my IP addresses):

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 3e:0a:12:4f:9d:64
          inet addr:46.101.39.xx  Bcast:46.101.63.yy  Mask:255.255.192.0
          inet6 addr: fe80::3c0a:12ff:fe4f:9d64/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7765 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12573 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:856215 (856.2 KB)  TX bytes:4933667 (4.9 MB)

eth1      Link encap:Ethernet  HWaddr aa:61:fa:a4:81:77
          inet addr:169.254.72.zz  Bcast:169.254.255.255  Mask:255.255.0.0
          inet6 addr: fe80::759e:acbc:907d:ef91/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:46798 (46.7 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:3091 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3091 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:257445 (257.4 KB)  TX bytes:257445 (257.4 KB)

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         46.101.0.1      0.0.0.0         UG    202    0        0 eth0
10.16.0.0       0.0.0.0         255.255.0.0     U     0      0        0 eth0
46.101.0.0      0.0.0.0         255.255.192.0   U     202    0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     203    0        0 eth1

$ ping -c3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

$ ping -c3 46.101.0.1
PING 46.101.0.1 (46.101.0.1) 56(84) bytes of data.

--- 46.101.0.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2015ms

And here are a few observations:

  • I have no idea at all what the eth1 interface is. It’s not in /etc/network/interfaces, and I can’t remember having seen it before (but then I never had the need to do network debugging on this droplet before).
  • I cannot bring eth1 down using ifdown (Unknown interface eth1) though using ifconfig down eth1 works (and doesn’t make any difference).
  • I cannot even ping my default gateway.
  • I use ufw firewall, but it’s allowing all outbound connections. tail -F /var/log/syslog while doing pings doesn’t show anything being logged (logging is enabled for ufw).

I’m getting desparate here. Does anyone have any suggestions?


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

@nanos

To make sure the firewall isn’t the cause, can you run:

sudo ufw disable

Then try to connect again. If it so happens that ufw was the actual cause, then it’s most likely some sort of misconfiguration that we can easily resolve by flushing the current rules and then setting new rules up.

To do that, we’d first run:

sudo ufw reset

Then setup our new rules (as that just flushed all the old).

sudo ufw default deny incoming
sudo ufw default allow outgoing

With the basic incoming/outgoing rules set, we now need to define the ports we will allow connection on. In this example, I’ll use 22 (SSH), 80 (HTTP) and 443 (HTTPS).

You can add any other ports that you need to the list.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Finally, we’ll re-enable ufw and confirm that we want to enable it.

sudo ufw enable

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

I did a reboot and same thing happening. Can’t access any outbound traffic.

After dist-upgrading, I did a reboot, and can’t do ANYTHING anymore. Incoming traffic works, and websites on my droplet are working fine, however, I can’t git clone, do apt get.

I’ve followed the steps in this thread, reset my iptables, reset ufw, yet, nothing worked so far.

What kinda update did DO ship to us?

@nanos

No problem, glad I was able to somewhat help a bit, though the final resolution was all you :-).

One thing to note, for future reference, is that snapshots are full-state backups. This means they take a snapshot of the state of the machine as it is when you run the action. When you restore a backup, it will restore state as it was when the snapshot was taken, which is why restoring a snapshot will not work when an issue like this arises.

Think of a snapshot as an image (such as an ISO). It creates an image of the entire machine, so when it comes to networking, that’ll come along with it. One of the IP’s may change (the main) if it’s restored to a Droplet with a different IP, but any other networking that may be in place will still remain.

For that very reason, I normally rely on on-server backups, block storage (to transfer the backups to), and other means of backup. In some cases, it’s simply better to start from scratch. It can be a pain, but that’s one reason I’ve started creating bash scripts to automate these things a long time ago.