Goal: have the IP addresses (both v4 and v6) of the tunnel lifted and working on the server, to be able to bind to them and listen to them (receive traffic from the internet) but without routing ALL server's traffic via the tunnel.

In IPv4, this can be easily solved by not adding redirect-gateway def1 in config file. This way the public IPv4 address of the tunnel is working on the server, server can listen on it and receive traffic on it but server's own traffic goes via the default ISP gateway . - good.

For IPv6, it only works with route-ipv6 ::\0. What this means it that ALL server's v6 traffic goes via the tunnel. And since (naturally) v6 is preferred over v4, all destinations on the internet (like update mirrors) are accessed using the tunnel. I don't want this. I want to be able to listen to IPv6 address of the tunnel, but not affect server's own traffic in any way.

If I remove ::\0 route, the server cannot be reached any more on v6 address of the tunnel, it does not reply to pings, etc. I tried replacing the route ::\0 with <ipv6>/64 and with Ipv6 gateway (IP with ::1 in the end). These 2 replacements don't work as v6 connectivity is not working entirely (the v6 address of the tunnel is not ping-able from the outside world).

How can this be fixed? I'd also like to connect more config files (tap0, tap1) that assign more /64 IPv6 subnets and use them concurrently, but as I said not for server's own traffic, only for received traffic.

Posting a reply here should it be useful in the future for someone searching for this.

This is not a problem related to OpenVPN and it cannot be tweaked by settings in OpenVPN configuration files. Because the selection of IPv6 over IPv4 preference is an Operating System policy, and happens on a much lower layer, the OpenVPN daemon itself has nothing to do with it. It is natural for any modern operating system (Linux, BSD, Windows) to prefer IPv6 over IPv4 generally - this is a sane and expected default. If one user wants to prefer IPv4 over IPv6, the operating system defaults need to be changed (in Linux: /etc/gai.conf ; in Windows: registry editor -> HKLM -> System .. tcpip6 DisabledComponents). Changing these will solve the problem so that IPv4 will be used as the default, and the default IPv4 gateway will dictate which IPv4 address to be used for internet traffic (the VPN one or the Wi-Fi / Ethernet one).

If the client connecting to the OpenVPN server would have its own IPv6 connectivity (not just the one from the vpn itself) the same goal could be accomplished by not using in client configuration file redirect-gateway ipv6 and ipv6-route <vpn_ipv6 vpn_ipv6_subnet> instead of global internet prefix (2000://3 or ::/0).

But in the scenario described in the first post of this topic, the client does not have IPv6 connectivity at all, and when he gets a global routable IPv6 prefix from the OpenVPN tunnel it naturally uses it as the default when connecting to hosts that are dual stacked and resolve to both IPv6 and IPv4 since IPv6 is preferred at operating system level policies.

Goal: have the IP addresses (both v4 and v6) of the tunnel lifted and working on the server, to be able to bind to them and listen to them (receive traffic from the internet) but without routing ALL server's traffic via the tunnel.

There are no valid options to route all the servers traffic via the tunnel ..

You can set it up manually but, of course, then the server will not function as a server because when the client tries to connect the server will route return packets via the tunnel and not to the connecting client.

But in the scenario described in the first post of this topic, the client does not have IPv6 connectivity at all, and when he gets a global routable IPv6 prefix from the OpenVPN tunnel it naturally uses it as the default when connecting to hosts that are dual stacked and resolve to both IPv6 and IPv4 since IPv6 is preferred at operating system level policies.

But your server has no IPv6 internet connectivity.

Personally, I don't really understand your goal which is why I did not respond before.