What the heck is this extra IP address that sometimes masquerades as a client IP?

When I request various pages from the local Apache virtual host (locally, from the same droplet) whose hostname resolves to a floating IP, the apache log shows two different IP addresses making the requests.

One of those IPs is my droplet’s anchor IP, as expected. The other one is from an address in the same subnet, but is not configured on my droplet.

Usually, and for most urls, it shows the anchor IP.

However, requests for certain urls (“/server-status”, for example) always appear to come from the other IP.

This is a problem for me because I want to limit access to certain pages from local and NATed tunnel address. However, I can’t do that until I know whether it is safe to allow access from this other pesky IP address: 10.10.0.2

Configured interface:

• The droplet has two interfaces: eth0 and lo.
• eth0 has only two addresses: my_server_ip and floating_ip_anchor
• Internal networking is not enabled.

ip addr show dev eth0

. . .
    inet 10.10.0.66/16 scope global eth0
. . .

Verified anchor address info:

$ for attr in address netmask gateway; do
    echo -n "${attr}="
    curl -s http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/$attr
    echo
done

address=10.10.0.66
netmask=255.255.0.0
gateway=10.10.0.1

Examples:

curl -IL https://www.mydomain.tld/server-status
curl -IL https://www.mydomain.tld/

HTTP/1.1 401 Unauthorized
. . .
HTTP/1.1 200 OK
. . .

10.10.0.2 - - [08/Jul/2017:23:43:53 -0400] "HEAD /server-status HTTP/1.1" 401 4449 "-" "curl/7.47.0"
10.10.0.2 - - [09/Jul/2017:00:06:59 -0400] "HEAD / HTTP/1.1" 200 4583 "-" "curl/7.47.0"
10.10.0.66 - - [09/Jul/2017:00:06:59 -0400] "GET /s/img/logo.png HTTP/1.1" 200 27233  "-" "curl/7.47.0"
. . .

Probably irrelevant, but FYI:

• The HTTP 401 is expected, as I have yet to allow access from 10.10.0.2 .
• The Apache server is actually proxying requests to a uwsgi instance.
  • uwsgi is listening on a domain socket and serving a django project.

Its not just Apache and HTTP:

• After shutting down Apache and related HTTP services, I can still ping 10.10.0.2.
• After inspecting some other log files, I noticed that ssh logins to the floating-ip-mapped hostname also appear to come from 10.10.0.2.

So, my first thought was that 10.10.0.2 is doing SNAT on traffic destined for my anchor IP

If that is true, it raises the question, “Is it even possible to safely control access based on IP addresses to hosts which resolve to a floating IP?”

The only problem with that hypothesis is that 10.10.0.2 only ever appears to make the request in two situations:

1. HTTP/HTTPS requests initiated from the droplet itself
2. SSH logins to the hostname in question from any remote address

All other connections, so far as I can tell, appear to come from the actual IP address of the requesting client.

If someone knows what actually is going on here, please let me know.