Can't make HTTPS requests to one of my droplets from other droplets; external works fine
I have a little API running on my site, here: https://shoptheroe.com/api/v1/status/
I'm able to
curl that and get a response from my local development machines just fine (from several different networks), but when I try to
curl it from a digital ocean droplet (running in the same datacenter, actually) quite often it times out:
$ curl --verbose https://shoptheroe.com/api/v1/status/ * Hostname was NOT found in DNS cache * Trying 184.108.40.206... * connect to 220.127.116.11 port 443 failed: Connection timed out * Failed to connect to shoptheroe.com port 443: Connection timed out * Closing connection 0 curl: (7) Failed to connect to shoptheroe.com port 443: Connection timed out
I don't have any firewall rules blocking HTTP from sibling DO droplets or anything like that... I am using a floating IP, which is what my DNS is pointing at.
The worst part is that sometimes it works just fine. It's an intermittent problem.
Here are my current
sudo iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 10.134.16.241 anywhere udp dpt:syslog ACCEPT tcp -- 10.134.16.241 anywhere tcp dpt:11211 ACCEPT tcp -- 10.134.16.241 anywhere tcp dpt:postgresql DROP tcp -- anywhere anywhere tcp dpt:postgresql ACCEPT tcp -- localhost anywhere tcp dpt:11211 DROP tcp -- anywhere anywhere tcp dpt:11211 ACCEPT udp -- localhost anywhere udp dpt:syslog DROP udp -- anywhere anywhere udp dpt:syslog Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
My firewall policy is to block everything that listens externally, and as I spin up additional droplets (for horizontal scaling) I punch holes for the new droplets based on their DO-private IP address. That's why you see those
10.134.16.241 rules. That's actually the machine I'm trying to the do the
curl command from, above. Anyways, I'm not blocking any
https traffic, so none of those rules should even matter...
Any ideas why this works fine from seemingly everywhere except DO itself?? Does DO itself have firewalls between machines within the same datacenter that might be blocking this?