Would I be correct to assume that Rails would ignore an X-Forwarded-For header when it’s value consists only of a single private IP?
This is what I see, running tcpdump inside the container, inspecting traffic to port 3000:
accept-encoding: gzip, deflate
content-type: application/x-www-form-urlencoded; charset=UTF-8
This is what i see doing tcpdump on eth0 inside the container, which seems to indicate that the original source address is being lost somewhere:
09:26:46.933458 IP 172.17.42.1.40710 > discuss.pirateint.org-app.https: Flags [.], ack 10524, win 2715, options [nop,nop,TS val 69777543 ecr 69777533], length 0
09:26:47.118145 IP 172.17.42.1.40710 > discuss.pirateint.org-app.https: Flags [P.], seq 19974:21368, ack 10524, win 2715, options [nop,nop,TS val 69777589 ecr 69777533], length 1394
09:26:47.122555 IP 172.17.42.1.40710 > discuss.pirateint.org-app.https: Flags [P.], seq 21368:21721, ack 10524, win 2715, options [nop,nop,TS val 69777590 ecr 69777533], length 353
I’m confused as to just how packets are making it to the container at all, considering the DNAT rules are never hit (the DOCKER chain is only referenced from the OUTPUT chain). I would guess, that it’s all going through docker-proxy, which (again, a guess) I imagine is why the source address is the docker host.
We haven’t customised anything aside from enabling SSL. The host has UFW, but only a few, very simple rules:
To Action From
-- ------ ----
22 ALLOW Anywhere
25 ALLOW Anywhere
220.127.116.11 995/tcp on docker0 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
22 (v6) ALLOW Anywhere (v6)
25 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
I’m a bit lost as to what’s happening here, as we also have another instance which seems to have the same firewall rules, yet it is working correctly (and the DNAT rules on that instance show many packets hitting them, as expected).