RESOLVED: Static IP Stopped Working - IP Range Blocked?

FlightAware ADS-B Flight Tracking
1

I am hosting a flight feeder on subnet 44.34.105.0/24 (IP address 44.34.105.11) - which was working fine until yesterday morning.

That subnet is routed using a Vultr virtual machine (compute instance)…and that VM cannot ping piaware.flightaware.com . I’ve tried my other compute instances and get the same thing. Sample MTR below:

redacted@207.148.14.174:~$ mtr --report piaware.flightaware.com
Start: 2024-01-18T14:30:44+0000
HOST: 207.148.14.174              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- 100.100.100.1              0.0%    10    1.0   1.1   0.8   2.3   0.5
  3.|-- 10.67.2.37                 0.0%    10    1.5   2.2   1.2   5.4   1.3
  4.|-- 10.67.3.13                 0.0%    10   18.3   4.3   1.0  18.3   6.1
  5.|-- eqix-ch2.cloudfare-02.com  0.0%    10    2.7   7.5   2.7  34.5  10.3
  6.|-- 172.69.56.5                0.0%    10    5.6   3.0   2.0   5.6   1.1
  7.|-- 172.69.57.112              0.0%    10    2.0   2.0   1.8   2.4   0.2
  8.|-- 172.69.57.69               0.0%    10    9.6   3.0   1.9   9.6   2.4
  9.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

I’ve also turned off all firewalls but have the same results. Other machines on the subnet work just fine, and other feeds are still working. To keep data flowing I moved the feeder to my home network, but it’s not optimal.

I’ve got a ticket open with Vultr but am not optimistic there, since they say if their IP ranges are being blocked they can’t do anything/very little. I can ping piaware.flightaware.com from my home network, on the cell phone, etc. so this appears to be a network/routing/blocking issue. Any thoughts as to where to go next?

2

Does Vultr have an internal firewall?

3

Only if configured. Since this is a router, I am not using their own firewall. In my troubleshooting I disabled the rules I had on device so it was clear/in the open. I’ve since re-enabled my inbound rules so I don’t get too much traffic/have other “issues.” lol.

2 Likes
4

Could this issue maybe have a relation with Cloudflare asking confirmation on not being a robot since yesterday ? Pinging and tracerouting are working fine but it might be be looking for confirmation?
Just a guess, and maybe it has to do something with your routing ?

5

I hadn’t seen that prompt until just now. As far as routing goes it could be. I had others check from their Vultr instances as well and same deal. Traffic fails at Cloudflare. So far no answer on my Vultr ticket.

6

since this is all new to me, how are you using cloudflared in the setup and can you take cloudflared out of the equation? (I’m a bit of a linux newbie, and I currently use cloudflared on my setup to run DNS over HTTPS for pihole, but that’s the extent of what I can do with cloudflared.

Additionally, and this may sound dumb, but do you think uninstalling/purging cloudflared and setting it back up again may fix it?

or am I missing the point and are you using 1.1.1.1/1.0.0.1 as your outside DNS resolver and not running cloudflared/a cloudflared tunnel on your linux system?

7

@obj is that something that can be followed up with the networking team?

@rickined1 Cloudflare is used by Flightaware as a service to protect the servers from unwanted traffic like Denial of Service attacks (DDOS) and spam robots etc.
This is a cloud service and not something you can arrange on your local feeder setup.

Most service providers use some form of this traffic checking ( or also called traffic shaping) in order to prevent sites getting overloaded and distributing traffic to multiple servers.

As a user you can’t manipulate that or change that, that’s up to the service provider ( in this case Flightaware).
So it has nothing to do with your DNS setting but with the traffic routing towards the FA sites.

1 Like
8

ok, this makes sense.so it is possibly something on FAs end… FWIW Cloudflared just pushed out a linux update within the last few days… wondering FA updated their servers and it broke something?
this is my Linux box’s cloudflared -v output
cloudflared version 2024.1.3 (built 2024-01-17-1027 UTC)

Looks like it was actually updated yesterday.

9

I’m not using Cloudflared on my end. The feeder is on an Internet address. I removed all firewalls from my gear for testing. DNS on the feeder is 8.8.8.8 and 8.8.4.4 . Names resolve correctly (I get a long list of IPs & none are reachable.

Flight aware IS using Cloudflare products to prevent robots/attacks tho.

1 Like
10

Vultr says: “It looks like they are blocking our ASN. Please check with them.”

Basically it’s out of my hands at this point. My subnet is a casualty because Vultr is hosting my BGP broadcast…and since it’s coming from their ASN…

11

Yeah, I’ve asked them about this, will let you know.

12

try now? (20 characters)

1 Like
13

@obj …THANK YOU! It works! Thanks for working w/them on this.

1 Like
14

even though it sounds like cloudflared wasn’t the issue, as an aside, cloudflare just pushed out another version today, so I’m assuming given the multiple versions in just 2 weeks that they are squashing bugs.

cloudflared version 2024.1.4 (built 2024-01-19-2025 UTC)
15

Thanks for that info. I have that running in a Docker container so I’ll expect to do a pull for those updates.

16

You may unfortunately run into this again – cloud providers are a common source of attacks (because the attackers spin up disposable VMs there to perform the attacks) so if/when we need to block them to mitigate an attack, your VM may be collateral damage.

1 Like
17

I fully expect it to be. We run into this at work as well. I’d love to find a smaller provider who would broadcast my subnet via BGP but up until recently haven’t found one. Still investigating.

18

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.