VTI IPv6 addresses don't get assigned
When a IPsec VPN has a v6 VTI phase 2assigned, the address is never assigned to the ipsecXXXX interface due to this error:
/vpn_ipsec.php: The command '/sbin/ifconfig 'ipsec2000' inet '2001:db8::2/126' '2001:db8::1'' returned exit code '1', the output was 'ifconfig: 2001:db8::2/126: bad value (width too large)'
If I manually assign the address with
'/sbin/ifconfig 'ipsec2000' inet6 '2001:db8::2/126 then the tunnel will happily pass IPv6 traffic between the addresses.
It seems that the v6 addresses are incorrectly identified as v4 and I also don't think that it is the correct syntax for v6 address as if I just change the
inet6 I get this error:
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
Updated by Ben Hughes over 2 years ago
It seems that the
is_ipaddrv6 function checks for a "/" in the address and if so decides it can't possibly be a v6 address, the PEAR Net_IPv6 module does correctly detect it as an IPv6 address but there this check is in there for compat reasons (not sure why). This is why it incorrectly tries to apply a v6 address as a v4 one. Also the command to apply it doesn't seem to be correct either.
So a quick and very dirty hack that seems to solve the problem (introducing what else I don't know) is:
In src/etc/inc/util.inc:665 comment out the check for
(strstr($ipaddr, "/")) and in src/etc/interfaces.inc:1441 alter the inet6 ifconfig call to remove the right side address and alias command.
That seems to reliably bring the VTI interface back up with both it's IPv4 and IPv6 addresses and allow traffic to pass, obviously it could do with a more production-ready fix but hopefully it makes that a little bit easier to implement.
Updated by Jim Pingle about 2 years ago
- Status changed from Feedback to Resolved
VTI IPv6 is assigned as expected and works on 2.4.5.a.20191220.0501
: ifconfig ipsec4000 ipsec4000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1299 tunnel inet 198.51.100.3 --> 198.51.100.20 inet6 fe80::20c:29ff:fe45:256%ipsec4000 prefixlen 64 scopeid 0x9 inet6 2001:db8:3:1111::1 prefixlen 64 inet 10.3.111.1 --> 10.3.111.2 netmask 0xfffffffc nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> reqid: 4000 groups: ipsec
: ping6 -S 2001:db8:3:1111::1 2001:db8:3:1111::2 PING6(56=40+8+8 bytes) 2001:db8:3:1111::1 --> 2001:db8:3:1111::2 16 bytes from 2001:db8:3:1111::2, icmp_seq=0 hlim=64 time=1.098 ms 16 bytes from 2001:db8:3:1111::2, icmp_seq=1 hlim=64 time=1.373 ms
(To another 2.4.5 system configured with the opposing addresses, so confirmed 2x)
Updated by Ben Hughes almost 2 years ago
I've just been testing this out on the latest RC version and it seems to be assigning the IPv6 a /32 subnet now for some reason, I see that the IPv4 is now netmask 0xffffffff so guessing the same code is catching both?
ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
tunnel inet 172.19.0.101 --> 172.19.0.102
inet6 fe80::250:56ff:fea2:2ac0%ipsec1000 prefixlen 64 scopeid 0x6
inet6 fdc7:5c33:b112:f010::1 prefixlen 32
inet 172.20.130.1 --> 172.20.130.2 netmask 0xffffffff
Updated by Jim Pingle almost 2 years ago
- Affected Version set to All
I just pushed a change which works on my test setup for existing and new connections.
The GUI still shows 0 but on the backend it assumes /64 when determining the address to use. Before it was only checking for tunnel6, and ignoring the IPv6 VTI case. IPv6 addresses are not setup point-to-point style so using /128 for VTI doesn't work. /64 is the safest assumption. Perhaps eventually we can allow the user to choose the prefix length in the GUI for IPv6 VTI, but that's a lot more complicated than we have time to do for 2.4.5.
Updated by DRago_Angel [InV@DER] over 1 year ago
Tried to configure it and doesn't have working solution on 2.4.5 release. How to accomplish this?
Tried to use uniq addresses e.g: fd4a:9b4d:f4e3:5ac4::1 and fd4a:9b4d:f4e3:5ac4::2 for remote. Tried put real addresses with dedicated /64 subnet in result have not assigned GW IP.
Updated by Jim Pingle over 1 year ago
It works for others. If it doesn't work for you, you need to post on a place where that can be diagnosed and discussed, like the forum. This bug report isn't the place to talk about why your particular config doesn't work. You don't even know for sure it's related to this bug. Take it to the forum.