port-share origin file scrambles IPv6 address

[jimc]

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
<tls-auth>

---

(snip)

---

</tls-auth>

[jimc]

CGI to report the client's IP address, plus proxy info if applicable.

[jimc]

CGI to return the content of a port-share origin file.

[Gert Döring]

It's well possible that this is broken for IPv6, or for "listen on dual-stack IPv4+IPv6 socket" setups. So if you are not using IPv4, you could use "--proto tcp4" to force IPv4.

But of course that would suck, and someone needs to go there and figure out what the code tries to do. There are still bits and pieces inside OpenVPN that assume "the world is IPv4", and you seem to have discovered a new one.

Patches welcome. Might be faster than waiting for us to dig into this.

CC'ing @syzzer, as he helped fix the last port-share-related bug :-)