IPv6 prefix delegation to OVPN interfaces
I got prefix delegation working for my DSL connection (fritz-> provider (xs4all)). With the setting "follow interface"
I get clear v6 adresses and subnets on my wired (ie REAL) interfaces. ipv6 works through these interfaces. Now,
when it comes to OVPN (server) interfaces, I only can set a tunnel network for v6 in the setup. (this is with 2.4.2)
On 2.2.5 I got this working by selecting a subnet within my v6 block, (in the openvpn settings as tunnel subnet)
but not used by the real interfaces, and not changing anything else (in other settings apart from ovpn).
I had v6 through openvpn with a correct v6 ip address on the client (which was within the selected tunnel
network (as it showed on the internet as well) and had routing to the internet). No problems there.
Getting the same setup working on 2.4.2, I get the idea that the dhcp6 client on WAN just asks and gets subnets for
the wired (real) interfaces, and does not request either the full v6 range or the subnets I select for the OVPN server
in pfsense, as I got outgoing packets from the ovpn client, and can ping6 alle real pfsense interfaces including the WAN
but not the router (fritz) and beyond. Yes, I have allowed ipv6* on the OVPN interface to * in firewall rules…..
Any idea here ?! The weird thing is that it looks that the behaviour (either dhcp6c or openvpnd) has changed
from 2.2.x -> 2.4.2
coreybrett last edited by
This may be related…
Yes, indeed it might, but still weird. without this proposed change it has worked in 2.2
I selected a prefix for the tunnel network that was within my (provider)assigned prefix,
where also the real interfaces IP#s were selected from. Also, yes, it was /64. this worked
in 2.2, but ceased to work in 2.4.2….
Many, many changes in OpenVPN between 2.2 and 2.4.2_1.
None of them should preclude IPv6 from working.
If you have a /64 from a PD that is not in use on a tracked interface and you have verified it is actually being routed to you, that should work as an OpenVPN tunnel interface.
That is, of course, much more viable if your ISP is honoring your DUID and your prefix isn't changing all the time.
I might have solved it by changing my (tunnel) subnet in openvpn.
It was 2001:xxxx:xxxx:FF:: changed it to 2001:xxxx:xxxx:ef:: according
to my real lan interface that got tracked to 2001:xxxx:xxxx:e4:xxxx:xxxx:xxxx:xxxx
It might be something weird with subnets :-) still do not understand that it worked before.
Still I am in favour of the feature request https://redmine.pfsense.org/issues/7281
Depends on the delegation.
For :00e4: and :00ff: to be in the same delegation it would have to be a /56.
:00ef: and :00e4: are in the same /60.