At the moment I've got no native IPv6 connection at my disposal to test my hypothesis but I don't think that the problem lies at the application level.
The apparent preference for IPv4 does not only seem to prevail in browsers but also in other applications like SSH. If I'm correct, SSH should prefer IPv6 over IPv4 on a native IPv6 connection, if one URL is pointing to multiple DNS entries (A + AAAA in this case). When a connection to a Gen2 server is established (via an IPv4 connection in my case), SSH always prefers IPv4 in my testing. An IPv6 connection to this specific URL can be forced with ssh -6 ... but this shouldn't be the default behavior of SSH.
What determines which connection should be preferred?
RFC3484 describes the ranking of competing connections. The resulting /etc/gai.conf on my Arch Linux system looks like this:
# All lines have an initial identifier specifying the option followed by
# up to two values. Information specified in this file replaces the
# default information. Complete absence of data of one kind causes the
# appropriate default information to be used. The supported commands include:
# reload <yes|no>
# If set to yes, each getaddrinfo(3) call will check whether this file
# changed and if necessary reload. This option should not really be
# used. There are possible runtime problems. The default is no.
# label <mask> <value>
# Add another rule to the RFC 3484 label table. See section 2.1 in
# RFC 3484. The default is:
#label ::1/128 0
#label ::/0 1
#label 2002::/16 2
#label ::/96 3
#label ::ffff:0:0/96 4
#label fec0::/10 5
#label fc00::/7 6
#label 2001:0::/32 7
# This default differs from the tables given in RFC 3484 by handling
# (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
# The reason for this difference is that these addresses are never
# NATed while IPv4 site-local addresses most probably are. Given
# the precedence of IPv6 over IPv4 (see below) on machines having only
# site-local IPv4 and IPv6 addresses a lookup for a global address would
# see the IPv6 be preferred. The result is a long delay because the
# site-local IPv6 addresses cannot be used while the IPv4 address is
# (at least for the foreseeable future) NATed. We also treat Teredo
# tunnels special.
# precedence <mask> <value>
# Add another rule to the RFC 3484 precedence table. See section 2.1
# and 10.3 in RFC 3484. The default is:
#precedence ::1/128 50
#precedence ::/0 40
#precedence 2002::/16 30
#precedence ::/96 20
#precedence ::ffff:0:0/96 10
# For sites which prefer IPv4 connections change the last line to
#precedence ::ffff:0:0/96 100
Which reflects the expected behavior described by the RFC standard. The man-page for this has been implemented in kernel 4.16 (very recently).
When I apply the little knowledge I have on IPv6, the ULA each OpenVPN connections gets assigned is part of:
label fc00::/7 6
and thus very low in the ranking of the competing connections.
Hopefully I could point you in the right direction. If not I'm sorry. I don't understand all of it but this seems plausible to me.