* Hannes Frederic Sowa > In its current form, not so good. If you can tell me specific software > that *breaks*, I can ask. At first I thought I might be able to just > switch an 'if' but the patch got a bit more complex.
What breaks is OpenVPN servers listening on an UDP IPv6 socket with IPV6_V6ONLY=0. If an IPv4 client attempts to set up a tunnel to a non-primary address of the server (for example in the case of a server with multiple interfaces or dedicated service OpenVPN service addresses), the OpenVPN process fails to use the address it was contacted on when replying to the client, instead using the default IPv4 source address of the system. This in turn leads to the tunnel failing to establish. See: https://community.openvpn.net/openvpn/ticket/306 FWIW: So far the "solution" has been to simply keep the UDP server IPv4-only, which works fine since with current versions of OpenVPN you have to explicitly ask for IPv6 to be used, which nobody (except I) does. However when OpenVPN 2.4 gets released the client will start using standard getaddrinfo() and thus prefer IPv6 when available, and then having no process listening on IPv6 in the server end becomes a real problem - nobody likes timeouts... > Maybe the workaround with IPv4 PKT_INFO does help for the time being. Probably, although I'm guessing Gert would rather not go there when your more proper fix is right around the corner. No worries, I'll look into backporting the patch to the kernel I'm currently running or upgrading to 3.14 once it's released. Thanks again! Tore
