[strongSwan] %any picks IPv6 link-local address
david at hardeman.nu
Tue Aug 23 01:40:27 CEST 2016
I'm using strongSwan 5.5.0 on my OpenWRT router to initiate a
site-to-site connection to strongSwan 5.2.1 (Debian stable) running on a
The remote server has static globally routable IPv4 and IPv6 addresses.
The OpenWRT router connects via PPPoE and receives a ::/56 subnet via
DHCPv6-PD. Fake (carrier-grade NAT:ed) IPv4 addresses are obtained via
This means that there's the following interfaces (I left out wifi
192.168.1.1/24 (internal network)
2001:xxxx/60 (globally routable IPv6 addr derived from my ::/56)
192.0.0.2/32 P-t-P 192.0.0.1/32 (ds-lite carrier-grade-NAT IPv4 addr)
If I use an ipsec.conf like this on the OpentWRT router:
Then strongSwan will try to initiate a connection using the link-local
address of the pppoe-wan interface (which fails), presumably because it
is the device used for outgoing IPv6 traffic. But pppoe-wan doesn't have
a global IPv6 address assigned.
The first line output by "ip -6 route" is:
default from 2001:xxxx/56 via fe80::12f3:11ff:fea3:2100 dev pppoe-wan proto static metric 512
I can fix it for now by:
1. explcitily specifying the IPv6 address of the router as "left="
2. using an IPv4 tunnel (i.e. "right=<server_global_ipv4_addr>" which
will pick 192.0.0.2 as the left addr)
3. assigning another global IPv6 address to "pppoe-wan"
Option 1 isn't very appealing because the ISP might change the IPv6 that
I'm assigned (hasn't happened yet but I know it has in the past).
Option 2 works (source address is set to 192.0.0.2) but I'd prefer to
not have to do NAT traversal and UDP encapsulation if it can be avoided
given that I do have a native IPv6 subnet.
Option 3 seems like a hack.
So, the question is if it'd be possible to take the "from 2001:xxxx/56"
part of the default route into consideration when selecting the source
IPv6 address? Or, alternatively, if it'd be possible to explicitly
specify the interface which the IPv6 source address should be picked
(I did try using charon.interfaces_ignore to ignore pppoe-wan, but that
broke the setup since the proper routing rules couldn't be created).
The same issue was reported by Daniel Pocock back in 2013:
More information about the Users