Opened 2 years ago

Last modified 2 years ago

#1358 new Bug / Defect

port-share origin file scrambles IPv6 address

Reported by: jimc Owned by: Gert Döring
Priority: major Milestone:
Component: IPv6 Version: OpenVPN 2.4.9 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: port-share IPv6
Cc: Steffan Karger


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,

  • 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= w3m -4 \

(alternatively w3m -6, or to
(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

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

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
port 443
dev tun1
topology subnet

keepalive 30 65

cd /etc/openvpn
writepid /run/openvpn/
verb 2
mute 10

server-ipv6 2600:3c01:e000:306::4:0/112
push "dhcp-option DNS"

port-share 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
ca /etc/ssl/ca/host.pth
dh /etc/ssl/hostcerts/dhparams.pem
cert /etc/ssl/hostcerts/hostw.cia
key /etc/ssl/private/hostw.key
key-direction 0



Attachments (2)

whatismyip.cgi (4.6 KB) - added by jimc 2 years ago.
CGI to report the client's IP address, plus proxy info if applicable.
proxysrc.cgi (4.0 KB) - added by jimc 2 years ago.
CGI to return the content of a port-share origin file.

Download all attachments as: .zip

Change History (3)

Changed 2 years ago by jimc

Attachment: whatismyip.cgi added

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

Changed 2 years ago by jimc

Attachment: proxysrc.cgi added

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

comment:1 Changed 2 years ago by Gert Döring

Cc: Steffan Karger added

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 :-)

Note: See TracTickets for help on using tickets.