Bug #9801
closed
VTI IPv6 addresses don't get assigned
Added by Ben Hughes about 5 years ago.
Updated over 4 years ago.
Description
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 inet to inet6 I get this error:
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
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.
- Status changed from New to In Progress
- Assignee set to Jim Pingle
- Target version set to 2.5.0
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
I've tested with the latest 2.5 development snapshot and it seems to be working correctly now.
- Status changed from Feedback to Resolved
- Target version changed from 2.5.0 to 2.4.5
- Status changed from Resolved to Feedback
Needs checked and/or tested again on 2.4.5 snapshots
I can do it but I can't see a download for 2.4.5 snapshot builds? Only 2.5.
They are not public yet, but will be soon. We are doing some internal testing to catch obvious issues before pushing them out.
- 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)
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
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 1000
groups: ipsec
- Status changed from Resolved to In Progress
Somehow it's not auto-setting the prefix length when saving. The one I already have in place is fine, but new ones are not.
- 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.
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
tested on 2.4.5.r.20200211.0854 and 2.5.0.a.20200211.1811
works as expected, /64 netmask
Yep can also confirm it seems to be working as expected.
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.
Post on the forum to discuss your problem.
This not forum question:
My VTI with IPv6 work well only if there no IPv4. And vise versa.
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.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Viktor Gurov 
Updated by