Project

General

Profile

Actions
Copy link

Bug #9801

closed

VTI IPv6 addresses don't get assigned

Added by Ben Hughes over 4 years ago. Updated almost 4 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:
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

Actions
Copy link
 #1

Updated by Ben Hughes over 4 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.

Actions
Copy link
 #2

Updated by Jim Pingle over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle
  • Target version set to 2.5.0
Actions
Copy link
 #3

Updated by Jim Pingle over 4 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Ben Hughes over 4 years ago

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

Actions
Copy link
 #5

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Resolved

Thanks for testing!

Actions
Copy link
 #6

Updated by Jim Pingle over 4 years ago

  • Target version changed from 2.5.0 to 2.4.5
Actions
Copy link
 #7

Updated by Jim Pingle over 4 years ago

  • Status changed from Resolved to Feedback

Needs checked and/or tested again on 2.4.5 snapshots

Actions
Copy link
 #8

Updated by Ben Hughes over 4 years ago

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

Actions
Copy link
 #9

Updated by Jim Pingle over 4 years ago

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

Actions
Copy link
 #10

Updated by Jim Pingle over 4 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)

Actions
Copy link
 #11

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

Actions
Copy link
 #12

Updated by Jim Pingle about 4 years 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.

Actions
Copy link
 #13

Updated by Jim Pingle about 4 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.

Actions
Copy link
 #14

Updated by Jim Pingle about 4 years ago

  • Status changed from In Progress to Feedback
Actions
Copy link
 #15

Updated by Viktor Gurov about 4 years 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

Actions
Copy link
 #16

Updated by Ben Hughes about 4 years ago

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

Actions
Copy link
 #17

Updated by DRago_Angel [InV@DER] almost 4 years 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.

Actions
Copy link
 #18

Updated by Jim Pingle almost 4 years ago

Post on the forum to discuss your problem.

Actions
Copy link
 #19

Updated by DRago_Angel [InV@DER] almost 4 years ago

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

Actions
Copy link
 #20

Updated by Jim Pingle almost 4 years 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.

Actions
Copy link

Also available in: Atom PDF