Project

General

Profile

Bug #9801

VTI IPv6 addresses don't get assigned

Added by Ben Hughes 10 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
Start date:
09/29/2019
Due date:
% Done:

100%

Estimated time:
Affected Version:
All
Affected Architecture:

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

Associated revisions

Revision 1d9fbb71 (diff)
Added by Jim Pingle 8 months ago

Correct VTI IPv6 test and syntax. Fixes #9801

Revision df1de4df (diff)
Added by Jim Pingle 8 months ago

Correct VTI IPv6 test and syntax. Fixes #9801

(cherry picked from commit 1d9fbb716543110ac245e2749f8c06fc77480a77)

Revision c519b62f (diff)
Added by Jim Pingle 5 months ago

IPsec VTI IPv6 address correction. Fixes #9801

When setting up IPv6 VTI, assume /64 -- Previous code was assuming /32
which wasn't correct, and it can't be /128 either since the IPv6
addresses are not point-to-point like IPv4.

Revision 68114fc1 (diff)
Added by Jim Pingle 5 months ago

IPsec VTI IPv6 address correction. Fixes #9801

When setting up IPv6 VTI, assume /64 -- Previous code was assuming /32
which wasn't correct, and it can't be /128 either since the IPv6
addresses are not point-to-point like IPv4.

(cherry picked from commit c519b62f8fc3ed094952c6289d21c429df139c51)

History

#1 Updated by Ben Hughes 10 months 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.

#2 Updated by Jim Pingle 8 months ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle
  • Target version set to 2.5.0

#3 Updated by Jim Pingle 8 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100

#4 Updated by Ben Hughes 8 months ago

I've tested with the latest 2.5 development snapshot and it seems to be working correctly now.

#5 Updated by Jim Pingle 8 months ago

  • Status changed from Feedback to Resolved

Thanks for testing!

#6 Updated by Jim Pingle 7 months ago

  • Target version changed from 2.5.0 to 2.4.5

#7 Updated by Jim Pingle 7 months ago

  • Status changed from Resolved to Feedback

Needs checked and/or tested again on 2.4.5 snapshots

#8 Updated by Ben Hughes 7 months ago

I can do it but I can't see a download for 2.4.5 snapshot builds? Only 2.5.

#9 Updated by Jim Pingle 7 months ago

They are not public yet, but will be soon. We are doing some internal testing to catch obvious issues before pushing them out.

#10 Updated by Jim Pingle 7 months 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)

#11 Updated by Ben Hughes 5 months 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
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
reqid: 1000
groups: ipsec

#12 Updated by Jim Pingle 5 months ago

  • 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.

#13 Updated by Jim Pingle 5 months 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.

#14 Updated by Jim Pingle 5 months ago

  • Status changed from In Progress to Feedback

#15 Updated by Viktor Gurov 5 months ago

  • 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

#16 Updated by Ben Hughes 5 months ago

Yep can also confirm it seems to be working as expected.

#17 Updated by DRago_Angel [InV@DER] 3 months 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.

#18 Updated by Jim Pingle 3 months ago

Post on the forum to discuss your problem.

#19 Updated by DRago_Angel [InV@DER] 3 months ago

This not forum question:
My VTI with IPv6 work well only if there no IPv4. And vise versa.

#20 Updated by Jim Pingle 3 months 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.

Also available in: Atom PDF