Project

General

Profile

Issue #694

IPv6 address assigned via CPREQ(ADDR6) is set to "deprecated", preferred_lft 0sec

Added by Markus Wernig about 6 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
kernel-interface
Affected version:
5.2.0
Resolution:
Fixed

Description

Hi all

I am using StrongSwan 5.2.0 on Gentoo Linux amd64 (kenel 3.16.0) against an OpenBSD 5.6 gateway with iked (IKEv2 daemon) to tunnel all IPv6 traffic from the client to the IPv6 internet via the gateway. While the connection succeeds without problems and the tunnel receives an "inner" ("virtual") IPv6 address, that interface is set to "deprecated", with a preferred life time of 0 sec.

Thus, the interface is only used when IPv6 connections are requested explicitly (ssh -6 $hostname or ping6 $hostname). But if $hostname has both A and AAAA records in DNS, the system (getaddrinfo) always prefers IPv4 (eg. with ssh $hostname), heedless of what I put into /etc/gai.conf.

Only after manually running "ip -6 addr change $ClientIPv6 dev wlan0 valid_lft 0xffffffff preferred_lft 0xffffffff" does the interface become fully usable.

Here's a quick setup overview:

/etc/ipsec.conf
        strictcrlpolicy=no
        charondebug="ike 4, enc 4, knl 4, cfg 2"    #useful debugs

conn %default
        ikelifetime=1440m
        keylife=60m
        rekeymargin=3m
        keyexchange=ikev1
        compress=no
        mobike=yes

conn mytunnel
        type=tunnel
        compress=no
        mobike=yes
        left=%defaultroute
        leftcert=client.crt
        leftid=client@my.domain
        leftauth=pubkey
        leftsourceip=%config
        right=$GatewayIPv4
        rightid=$GatewayFQDN
        rightauth=pubkey
        rightsubnet=::/0
        keyexchange=ikev2
        auto=add

Authentication, SA setup and IKEv2 CPREQ all work fine, but the interface results in:

ip addr show wlan0

wlan0: mtu 1500 qdisc mq state UP group default qlen 1000
  link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
  inet 192.168.0.2/24 brd 192.168.0.255 scope global wlan0
    valid_lft forever preferred_lft forever
  inet6 $ClientIPv6/128 scope global deprecated
    valid_lft forever preferred_lft 0sec
  inet6 fe80::aabb:ccdd:eeff/64 scope link
    valid_lft forever preferred_lft forever

After which the above command is required to make the client OS consider IPv6 when calling getaddrinfo.

Is there a particular reason why the interface is set to deprecated? Or is this some interoperability issue? Or a bug?

Krgds /markus

PS: I found the same issue reported here, but with no reply:
http://article.gmane.org/gmane.network.vpn.strongswan.user/8209


Related issues

Related to Bug #598: Wrong source IPv6 address selection for virtual address and split-tunnelClosed22.05.2014

History

#1 Updated by Markus Wernig about 6 years ago

I forgot: For the detailed setup, see here: http://markus.wernig.net/en/it/ip6tunnel-ipsec-only.phtml

#2 Updated by Tobias Brunner about 6 years ago

  • Description updated (diff)
  • Status changed from New to Feedback

PS: I found the same issue reported here, but with no reply:
http://article.gmane.org/gmane.network.vpn.strongswan.user/8209

Here is Martin's response: https://lists.strongswan.org/pipermail/users/2014-August/006433.html

See #598 for the reasoning behind the "fix". I wonder why the source route we install in routing table 220 does not help here.

#3 Updated by Markus Wernig about 6 years ago

See #598 for the reasoning behind the "fix".

OK, I understand. Even though I'm not sure why the interface should be excluded from source selection in all cases.

I wonder why the source route we install in routing table 220 does not help here.

Hm. Could it be because Linux (at least "my" Gentoo does) by default installs a ipv6 reject route on lo (see below), which does not get cleared when the new route is set?

$ netstat -6 -rn
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: Un 0 1 31 lo
$ClientIP6/128 :: Un 0 7 50975 lo
$ClientIP6/128 :: U 256 0 0 wlan0
fe80::aabb:ccdd:eeff:0011/128 :: Un 0 1 0 lo
fe80::/64 :: U 256 0 0 wlan0
ff00::/8 :: U 256 0 0 wlan0
::/0 :: U 1024 2 0 wlan0
::/0 :: !n -1 1 70 lo

#4 Updated by Tobias Brunner over 2 years ago

I pushed a patch to the ipv6-addrlabel branch that uses address labels instead of deprecation to force the kernel to prefer other addresses for physical connections.

#5 Updated by Tobias Brunner over 2 years ago

  • Related to Bug #598: Wrong source IPv6 address selection for virtual address and split-tunnel added

#6 Updated by Noel Kuntze almost 2 years ago

  • Category set to libhydra
  • Resolution set to Fixed

#7 Updated by Tobias Brunner over 1 year ago

  • Category changed from libhydra to kernel-interface

Has anybody actually tested the patch in the branch above (now rebased to the current master)? I only tried it in our testing environment, where the previous code also worked. So I don't know if this actually fixes the problem the OP had.

#8 Updated by Tobias Brunner over 1 year ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner

The change above was released with 5.8.0 (00a953d090).

Also available in: Atom PDF