IPv6 patch mysteriously breaks IPv4 VPN

Valdis Kletnieks
2016-04-21T02:24:26Z

[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]

I'll say up front - no, I do *not* have a clue why this commit causes this
problem - it makes exactly zero fsking sense.

Scenario: $WORK is blessed with a Juniper VPN system. I've been
seeing for a while now (since Dec-ish) an issue where at startup,
the tun0 device will get wedged. ifconfig reports this:

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1400
inet 172.27.1.165 netmask 255.255.255.255 destination 172.27.1.165
inet6 fe80::6802:d95c:f3f4:2a6f prefixlen 64 scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 48 (48.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

and no more packets cross - not even a ping.

Yes, the tunnel is ipv4 only, and only ipv4 routes get set by the VPN software.

bisect results confirmed - linux-next 20160327 is bad, but 20160420 with this
one conmmit reverted works.

% git bisect bad
cc9da6cc4f56e05cc9e591459fe0192727ff58b3 is the first bad commit
commit cc9da6cc4f56e05cc9e591459fe0192727ff58b3
Author: BjÃ¸rn Mork <bjorn@mork.no>
Date: Wed Dec 16 16:44:38 2015 +0100

ipv6: addrconf: use stable address generator for ARPHRD_NONE

Add a new address generator mode, using the stable address generator
with an automatically generated secret. This is intended as a default
address generator mode for device types with no EUI64 implementation.
The new generator is used for ARPHRD_NONE interfaces initially, adding
default IPv6 autoconf support to e.g. tun interfaces.

If the addrgenmode is set to 'random', either by default or manually,
and no stable secret is available, then a random secret is used as
input for the stable-privacy address generator. The secret can be
read and modified like manually configured secrets, using the proc
interface. Modifying the secret will change the addrgen mode to
'stable-privacy' to indicate that it operates on a known secret.

Existing behaviour of the 'stable-privacy' mode is kept unchanged. If
a known secret is available when the device is created, then the mode
will default to 'stable-privacy' as before. The mode can be manually
set to 'random' but it will behave exactly like 'stable-privacy' in
this case. The secret will not change.

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: å‰è—¤è‹±æ˜Ž <hideaki.yoshifuji@miraclelinux.com>
Signed-off-by: BjÃ¸rn Mork <bjorn@mork.no>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

(Sorry for the delay in reporting this - bisecting this proved to be
a bear and a half, because this problematic commit landed only about 10 commits after
this one:

git bisect start
# good: [1bd4978a88ac2589f3105f599b1d404a312fb7f6] tun: honor IFF_UP in tun_get_user()

which fixed a *different* issue that prevented the tun device from getting
created at all (or it was immediately taken back down by the VPN software).
End result was that unless I gave a "known good" start point in that dozen
commit range, there's be a month's worth of 'git commit skip' to wade through.
I got damned lucky and found a record on one of my servers of an ssh over VPN,
and correlated it to the one day that linux-next had the above fix for the
previous issue, and wasn't broken by this current issue....)

[-- Attachment #2: Type: application/pgp-signature, Size: 848 bytes --]