Recently, we were looking through our access logs to troubleshoot a bug and noticed a number of anomalous requests from IP addresses operated by Cloudflare.
We use realip with Nginx, so we typically expect to pull the real IP address of the end user from the last trusted element of the X-Forwarded-For header. We also log both X-Forwarded-For and CF-Connecting-IP separate from the IP address that realip chooses.
Because of this configuration, we typically only expect to see Cloudflare IP addresses when our site is visited by the AlwaysOnline bot or Cloudflare staff members. However, our logs showed requests that didn’t fit into either of those categories starting in September.
When we took a closer look at the requests, we noticed that:
- They all originated from desktops, not mobile devices, indicating that Warp wasn’t in use. Exclusively desktop–zero mobile requests.
- The user agents often indicated that a user was likely technically inclined (e.g., Linux).
- When the IP addresses were IPv6, they were often in
2a09:bac0::/32. Despite being announced by AS13335 (Cloudflare), that range isn’t in Cloudflare’s list of IP addresses that they operate, which makes sense for IP addresses used by Warp.
- A WHOIS query on the allocation (RIPE) shows
- Often requests would switch between residential IP addresses and Cloudflare IP addresses with zero delay. A series of requests would come in from a session on a residential IP address, and within milliseconds, more requests would come in from the same session, but on a Cloudflare IP address. It would later switch back, again with zero delay.
- X-Forwarded-For and CF-Connecting-IP both showed the anomalous Cloudflare IP addresses. There was never an additional residential IP address in X-Forwarded-For.
We contacted one of our users whose requests were seen coming from Cloudflare IP addresses. They informed us that they have 18.104.22.168 configured as the DNS server in their router. Based on further investigation and analysis, we believe most or all of the anomalous requests originated from people who were using 22.214.171.124 as a DNS server but were not using Warp.
When people use Warp from a mobile client, we see their real IP address without issue. We haven’t found any cases in which we saw a Cloudflare IP address in place of a real IP address for a Warp user. This only seems to affect people using 126.96.36.199 for DNS, but not as a VPN.
This leaves us with several questions:
- Why are Warp IP addresses sometimes being reported in place of real IP addresses when people aren’t actually using Warp?
- Why does this seem to affect people who are using 188.8.131.52 as a nameserver, but not as a VPN?
- How is this even possible? It doesn’t make sense that Cloudflare’s HTTP servers would be aware of whether someone is using 184.108.40.206 as a DNS server. Is this a bug that can affect any request, and the correlation with 220.127.116.11 just a crazy coincidence, or is 18.104.22.168 sometimes serving different A/AAAA records than would otherwise be expected?
Here’s an example request from two days ago:
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
- IP address that actually made the request (typically the Cloudflare PoP):