Connections fails if using tls-auth, tls-crypt, and tls-crypt-v2 and server has a IPv6 privacy (RFC 4941) address #304
Comments
|
Please provide also client logs and logs. You probably need the |
|
I can confirm that I already posted the server logs, it's literally those few lines repeated infinite times. The client log just says: |
|
Hi,
On Mon, Apr 03, 2023 at 08:41:40AM -0700, Brian Turek wrote:
I can confirm that `multihome` fixes the problem! Given that privacy addresses are widely recommended, I feel like this potentially needs a better solution as machines can get *many* IPv6 addresses.
`multihome` is exactly the solution for it - ensure that things work
if a machine has multiple IPv4 or IPv6 addresses, and you do not want
to bind to one specifically.
(As a side note, somewhat off-topic - IPv6 people have stopped really
recommending privacy addresses, because they are mostly a pain for
admins, while not fulfillin the promise of "privacy" since browsers
tell the tracking people everything they want)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
|
Fair enough, thank you for the pointer to I am not a expert in IPv6 by any means but I believe that Windows since XP SP1, macOS since (Mac OS X) 10.7, Android since 4.0, and iOS since version 4.3 all use privacy addresses by default (per Wikipedia). It may be less common on servers but it's definitely prevalent on the client side. |
|
Hi,
On Tue, Apr 04, 2023 at 08:28:26AM -0700, Brian Turek wrote:
I am not a expert in IPv6 by any means but I believe that Windows since XP SP1, macOS since (Mac OS X) 10.7, Android since 4.0, and iOS since version 4.3 all use privacy addresses by default (per Wikipedia). It may be less common on servers but it's definitely prevalent on the client side.
It is, but when Windows XP SP1 was current, people thought that privacy
IPs were a good thing, like 15 years ago... in the meantime the landscape
has changed a lot, tracking has never really been done on IP address
(because of NAT on IPv4) so all the marketing folks found other ways,
and the remainder of IPv4 privacy addresses is "mostly nuisance".
But yeah, I've seen discussions in the team about making `multihome`
on-by-default. It was optional for the longest time because it did not
work right on all platforms, but that has been fixed in recent years.
gert
…--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany ***@***.***
|
Describe the bug
IPv6 clients cannot connect to a IPv6 server using tls-auth, tls-crypt, or tls-crypt-v2 if the server has a IPv6 privacy (RFC 4941) address present/allocated; even if the client is connecting to the "base" address. Here is the log snippet if the server has a IPv6 privacy address (client address is slightly redacted):
After a significant number of failures, it eventually tries IPv4 and is successful.
Here is the log if I disable the IPv6 privacy address on the server (DNS is the same, nothing else changes, etc) which is successful:
To Reproduce
Expected behavior
Connection to be successful
Version information (please complete the following information):
Additional context
This post tipped me off: https://forums.openvpn.net/viewtopic.php?t=35101
The text was updated successfully, but these errors were encountered: