Opened 4 years ago

Closed 4 years ago

#1282 closed Bug / Defect (fixed)

No IPv6 connectivity if client gets assigned the first IP of the /64 block

Reported by: NicolaF_ Owned by: Gert Döring
Priority: minor Milestone: release 2.5
Component: IPv6 Version: OpenVPN git master branch (Community Ed)
Severity: Patch Queue: New / awaiting ACK Keywords:
Cc: Antonio Quartulli

Description

Hi,

With the attached server configuration, if a client gets assigned the fitst IPv6 of the 64 block, ie. <VPN ipv6 prefix>::0 , it has not IPv6 connectivity. Packets gets lost. He gets the first IPv4 too (192.168.40.1, .0 in ipp.txt), but IPv6 works fine.

Strangely enough, the incriminated IPv6 responds to ping even if no client is connected:

root@OpenWrt:~# ping <VPN ipv6 prefix>::
PING <VPN ipv6 prefix>:: (<VPN ipv6 prefix>::): 56 data bytes
64 bytes from <VPN ipv6 prefix>::254: seq=0 ttl=64 time=0.377 ms
64 bytes from <VPN ipv6 prefix>::254: seq=1 ttl=64 time=0.262 ms
64 bytes from <VPN ipv6 prefix>::254: seq=2 ttl=64 time=0.257 ms
64 bytes from <VPN ipv6 prefix>::254: seq=3 ttl=64 time=0.261 ms
^C
--- <VPN ipv6 prefix>:: ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.257/0.289/0.377 ms

Workaround: add a dummy entry in ipp.txt to ensure that no client gets the first IP

Cheers,
NicolaF_

Attachments (1)

server.conf (969 bytes) - added by NicolaF_ 4 years ago.
Server configuration

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by NicolaF_

Attachment: server.conf added

Server configuration

comment:1 Changed 4 years ago by NicolaF_

Typo: but IPv6 works fine -> but IPv4 works fine

comment:2 Changed 4 years ago by tct

Looks like it depends on this:

ifconfig-ipv6-pool <VPN ipv6 prefix>::/64

Last edited 4 years ago by tct (previous) (diff)

comment:3 Changed 4 years ago by Gert Döring

Cc: Antonio Quartulli added
Milestone: release 2.4.7release 2.5
Priority: majorminor
Status: newassigned
Version: OpenVPN git master branch (Community Ed)

Better workaround: configure the pool as <vpn ipv6 prefix>::1/64, done.

::0 is the subnet router anycast address, and all the routers on the network will answer to ND requests for it, so it's not really usable for regular client use (unless the network is a /127, in which case it's generally allowed)

That said, OpenVPN should not give out ::0 to clients. Need to look into the pool handling ("if start address is 0, set to 1"). 128 bit math again, ugh.

And double-ugh to port this back to 2.4, which has very different code there.

comment:5 Changed 4 years ago by Gert Döring

Severity: Not set (select this one, unless your'e a OpenVPN developer)Patch Queue: New / awaiting ACK

comment:6 Changed 4 years ago by Gert Döring

Resolution: fixed
Status: assignedclosed

Patch has been applied to the master and release/2.5 branch.

Release/2.4 has the same "unintended feature", but the pool code is sufficiently different that this patch will not work - I do not see this as highly significant problem ("a documented workaround exists"), so do not currently plan to backport it.

commit 4dff236811a1ec9c97a27ad93182ad4beb12377f (master)
commit 611382c16cbac83195cc0fd4825553dad149ff9a (release/2.5)
Author: Gert Doering
Date: Thu Sep 17 10:59:41 2020 +0200

If IPv6 pool specification sets pool start to ::0 address, increment.

Note: See TracTickets for help on using tickets.