ipx-web strips Cloudflare Access headers from the tunnel too #209
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during the #203 cutover. Caddy listens dual-stack in the container, so a connection from the ipx_default gateway arrives as ::ffff:192.168.64.1. The Caddyfile's
remote_ip {$TUNNEL_PEER}(192.168.64.1) does not match the IPv4-mapped form, so Caddy strips Cf-Access-* from cloudflared's requests as from anyone else's, and Access sign-in through ipodderx.sdf1.net falls back to the password form. Shown with netstat in ipx-web and a forged-signature Access token that never reached ipx's token check. The browser suite missed it: there Caddy binds 127.0.0.1, IPv4 only.Not a bug. Caddy reports an IPv4 peer as plain IPv4 on its dual-stack socket (checked with caddy respond in the container), so remote_ip 192.168.64.1 matched all along. The stripped headers came from testing on Tower itself: its requests reach the published port as 192.168.1.130, rightly not the tunnel. From a container on cloudflared's network a forged Access token reaches ipx's check and is refused (InvalidSignature). The change is reverted in
0c820bb.