netdev - Re: [PATCH v2 net] ipv6: addrconf: fix Juniper SSL VPN client regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20fb5234-63d4-dce3-a6fd-1d943639142c@stressinduktion.org>
Date:	Tue, 12 Jul 2016 10:32:00 -0400
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>, bjorn@...k.no
Cc:	netdev@...r.kernel.org, Valdis.Kletnieks@...edu, jonas@...puner.ca,
	hideaki.yoshifuji@...aclelinux.com
Subject: Re: [PATCH v2 net] ipv6: addrconf: fix Juniper SSL VPN client
 regression

On 11.07.2016 16:48, David Miller wrote:
> From: Bjørn Mork <bjorn@...k.no>
> Date: Mon, 11 Jul 2016 16:43:50 +0200
> 
>> The Juniper SSL VPN client use a "tun" interface and seems to
>> be picky about visible changes.to it. Commit cc9da6cc4f56
>> ("ipv6: addrconf: use stable address generator for ARPHRD_NONE")
>> made such interfaces get an auto-generated IPv6 link local address
>> by default, similar to most other interface types. This made the
>> Juniper SSL VPN client fail for unknown reasons.
>>
>> Fixing this regression by adding a new private netdevice flag
>> which disables automatic IPv6 link local address generation, and
>> making the flag default for "tun" devices.
>>
>> Setting an explicit addrgenmode will disable the flag, so userspace
>> can choose to enable automatic LL generation by selecting a suitable
>> addrgenmode.
>>
>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=121131
>> Fixes: cc9da6cc4f56 ("ipv6: addrconf: use stable address generator for ARPHRD_NONE")
>> Reported-by: Valdis Kletnieks <Valdis.Kletnieks@...edu>
>> Reported-by: Jonas Lippuner <jonas@...puner.ca>
>> Suggested-by: Hannes Frederic Sowa <hannes@...essinduktion.org>
>> Cc: 吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
>> Signed-off-by: Bjørn Mork <bjorn@...k.no>
> 
> What really irks me is that we "fixing" something without knowing what
> actually is the problem.
> 
> Someone needs to figure out exactly what is making the Juniper thing
> unhappy.  It really shouldn't care if a link local address is assigned
> to the tun device, this is fundamental ipv6 stuff.

I agree, but there could be a lot of factors affecting this. For example
we know start to send out an icmp router solicitation into the vpn as
soon as the link goes up, as well as initial mld change record. It could
very well trigger security software and kill the VPN (something I can
very well imagine right now).

I actually don't suspect something funny going on in the Juniper's Java
client itself, this would just be too strange. Unfortunately I don't
have access to such systems to check what could be the problem.

Bjorn send a list of things that could be tried.

Thanks,
Hannes