id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 1358,port-share origin file scrambles IPv6 address,jimc,Gert Döring,"The reason I'm messing with port-share client reporting is that I want to test if my Tor server is working. The test has these hops, many involving my semi-bastion host Claude and/or one of my wild-side gateways Surya or Jacinth. * An internal host (laptop) runs w3m (-4 or -6) with https_proxy. The URL (see below) is for the wild-side address of the gateway. * Proxy traffic goes to Privoxy on Claude port 8118. * It is forwarded (forward-socks5t) to Tor on Claude port 9050. This forwarded traffic is confirmed by tcpdump -i lo port 9050 * The Tor daemon sends it out to the cloud. * The Tor exit node sends the traffic to my wild side, surya.jfcarter.net. * OpenVPN on Surya proxies the traffic over to the webserver on Claude. * Claude runs a script (whatismyip.cgi) reporting the client's IP. When it recognizes a proxy situation, it does a HTTP query back to the gateway, specifying the proxy's IP and port in its query-string. * Surya's proxysrc.cgi looks in OpenVPN's proxy reporting directory, and assuming the file was found (it was never seen to fail), it sends back the file's content. * Claude's whatismyip.cgi sends back through the various hops a report of the client's IP (plus proxy info if applicable). * If the client IP belongs to a Tor exit node (or more realistically, doesn't belong to anything I recognize), then I get a simple positive confirmation that my Tor setup is working. * The command line on the laptop was: https_proxy=https://claude.cft.ca.us:8118/ w3m -4 \ https://surya.jfcarter.net/whatismyip.cgi?debug (alternatively w3m -6, or to jacinth.jfcarter.net) (for extra debugging info, give a query-string of 'debug'.) * Why aren't I using the Tor browser directly? Because most of the traffic to be protected by Tor is non-HTTP. * For the back story on why I have two gateways, Surya and Jacinth, one could take a quick look at https://www.jfcarter.net/~jimc/documents/cloud-server-1901.html The problem occurs in openvpn-2.4.9-1.1.x86_64 from OpenSuSE Tumbleweed. To avoid public wireless nets that block VPNs, I have OpenVPN on my gateway Surya port 443/tcp (as well as 1194/udp), and port sharing with this configuration command: port-share claude.cft.ca.us 443 /var/lib/wwwrun/openvpn-ps (Complete file below.) It successfully forwards non-OpenVPN traffic (always HTTPS) to the webserver Claude. It always uses IPv4; it's never been seen to use IPv6 though that would work if used. The symptom is that the client address in the origin file is incorrect. First, it is always reported as [AF_INET6] even for client ""w3m -4"". Then, even on authentic IPv6 the trailing 64 bits are not recognizable; they seem randomized. The leading 64 bits are at least partially correct: from w3m -6 on my laptop direct to Surya, the prefix of my LAN is seen intact; from my cellphone (on cellular data, LTE, IPv6) to Surya, the first 32 bits belong (per whois) to my carrier and I wouldn't know what the next 32 should be; and with an IPv4 source address (w3m -4) mapped to IPv6 the first 64 bits should be and are zero, although the expected FFFF is not seen and 16 or 32 bits of 0 are seen at the end, the rest being random. Assuming the bug tracker will allow it, I'm attaching the two scripts mentioned, though you will have to adjust the loginID of the executing user (wwwrun), the location of the origin file directory, and the address(es) of the OpenVPN/proxy server(s). To see the bug in action (or results after fixing) you're welcome to access the URL in the first section. OpenVPN configuration file minus most comments: Settings are (mostly) in the order appearing in the OpenSSL man page. mode server # Could it be that tcp6-server causes IPv4 clients to appear as mapped IPv6? proto tcp6-server float port 443 dev tun1 topology subnet ifconfig-nowarn tcp-nodelay keepalive 30 65 ping-timer-rem persist-tun persist-key persist-local-ip persist-remote-ip mlock cd /etc/openvpn writepid /run/openvpn/surya443.pid fast-io verb 2 mute 10 server 192.9.200.152 255.255.255.248 server-ipv6 2600:3c01:e000:306::4:0/112 push ""dhcp-option DNS 192.9.200.193"" client-to-client duplicate-cn port-share claude.cft.ca.us 443 /var/lib/wwwrun/openvpn-ps auth SHA256 ncp-ciphers AES-256-GCM:AES-256-CBC:AES-256-CFB:AES-128-GCM:AES-128-CBC:AES-128-CFB cipher AES-256-CBC compress lzo tls-server ca /etc/ssl/ca/host.pth dh /etc/ssl/hostcerts/dhparams.pem cert /etc/ssl/hostcerts/hostw.cia key /etc/ssl/private/hostw.key tls-cipher DEFAULT:+aRSA:+SHA:!aNULL:!DES:!3DES:!RC4:!MD5:!PSK:!DSS:!CAMELLIA:!SEED:!SRP:!AES256 key-direction 0 -----BEGIN OpenVPN Static key V1----- (snip) -----END OpenVPN Static key V1----- ",Bug / Defect,new,major,,IPv6,OpenVPN 2.4.9 (Community Ed),"Not set (select this one, unless your'e a OpenVPN developer)",,port-share IPv6,Steffan Karger