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)
Change History (7)
Changed 4 years ago by
Attachment: | server.conf added |
---|
comment:2 Changed 4 years ago by
Looks like it depends on this:
ifconfig-ipv6-pool <VPN ipv6 prefix>::/64
comment:3 Changed 4 years ago by
Cc: | Antonio Quartulli added |
---|---|
Milestone: | release 2.4.7 → release 2.5 |
Priority: | major → minor |
Status: | new → assigned |
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
Severity: | Not set (select this one, unless your'e a OpenVPN developer) → Patch Queue: New / awaiting ACK |
---|
comment:6 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
Server configuration