Okay I see what you're saying. With this option turned on, when you kill radvd, it basically sends a weird "okay, good night and good luck" message on its way out the door which clients will hopefully pick up and expire their discovered prefixes (The manpage says "encourage") If they hear it.

Cool trick (and not a thing I've ever seen real Cisco routers do), and maybe radvd could be extended to continue sending that expired prefix notification even after a restart, if it can pick up that stale prefix from somewhere, but this post is about OpenVPN.

OpenVPN clients don't listen to RA's. They use their own internal DHCPv6-like implementation (where the server tracks and assigns ips), and which subnet the server uses is never magically picked up from the interface, since it's not on the interface.

Unless I'm misunderstanding you?

The radvd service gets shutdown then started indirectly via /etc/rc.newwanipv6 (which gets called by dhcp6c).

IIRC with dynamic PDs what should happen is that after the PD changes there's an RA sent to clients saying that the old prefix is no longer valid. I'm not sure about the persistence of that though (e.g what if the client never got the RA).

Then maybe sending it again for as long as the Lifetime was?
Whatever it takes, in my mind, one could capture what router X is sending to clients and then just do the same in pfSense. The latter is the hard part I guess.

But there is no need to hijack this thread. And while my prefix is changing daily, for others it might be stable for many months.

On prefix expiry: RA's probably wouldn't be in play here. RA's are generally static broadcasts that the router emits, and wouldn't be stated to a particular client.

Expiry/nonrenewal would be handled when the client attempts to renew the DP, which it would do, same as its normal v6 address lease. RA's would just set the managed/other flags and leave the client up to DHCP.

On the feature in "Wan" you mentioned: Yeah, but "OpenVPN" isn't an interface in the traditional sense. I've definitely used the "track interface" feature to give my LAN one of my designated prefixes. It's what I based the work I did here on. (Same idea, tell openVPN "you've been given M prefixes, use number N of those, where "1" is LAN, typically).

-Dan

The 6rd option is there partly because its implementation was small in scope (code-wise). Supporting regular DHCPv6 PD is much more involved and really warrants a rewrite of dynamic prefix handling in general. This would ideally happen after replacing dhcpc.

IIRC with dynamic PDs what should happen is that after the PD changes there's an RA sent to clients saying that the old prefix is no longer valid. I'm not sure about the persistence of that though (e.g what if the client never got the RA).

Side note, there's also an advanced option in WAN configuration to designate a PD to any interface. I've never seen it used though. There's even the option to provide your own client script entirely.

Because I'm curious, what other router are you using?

PFSense is developed using Kea (and ISC DHCPd), which is written to be standards-compliant. But that's a "general prefix delegation" thing and doesn't have anything specific to do with OpenVPN's support of it, which is what this topic is about.

there's no easy way to pass that notification on to tell clients to use that new prefix, until those clients' own DHCP lease expires.

Other routers can do it, so that doesn't count to me. Now if your problem is different and not too close related, then I will keep my mouth shut.

DHCPv6 Prefix delegation happens as a function of DHCPv6, but there's a problem there inherent in the protocol.

A PFSense box is both a client and a server of DHCPv6.

When the server (upstream) gives you a new prefix, there's no easy way to pass that notification on to tell clients to use that new prefix, until those clients' own DHCP lease expires. Clients also don't have a magic way of knowing "it's not working, it must be my lease, let me try renewing it". You can fix this by making lease times shorter, but the defaults are pretty sane.

Obviously the best way to handle this is to keep things as steady as possible, and don't change delegated prefixes more often than is absolutely necessary (when you get a new cable modem with a new MAC address, when you move to a new area, if your ISP needs to renumber), since the whole point of prefix delegation is about "we're handing out lots of global IPs that lots of devices will use", but it's not perfect. (With ipv4 and NAT, this isn't a problem, pfsense just NAT's behind the new IP, and life is good).

The thing I am trying to fix is "not having to actually update hard-coded configuration details when my delegated prefix changes". (Did you read this thread?).

Yes, just like with a wired configuration on a tracked LAN PD prefix, it will require a release/renew, but that happens more regularly in OpenVPN setups anyway, than in a desktop PC which may just be always-on-and-plugged-in.

That's different from solving a general problem inherent in prefix-delegation in general.

The code I submitted has a hook for when a delegated prefix changes.

Nice. But again, it is not even working that good in pfSense in general. Hard to believe, your OpenVPN patch isn't affected by this general behavior. But I am no coder, just telling what I am seeing.

The code I submitted has a hook for when a delegated prefix changes.

6RD is an old transition mechanism, "ipv6 rapid deployment". It is not common today. It's used when some of your equipment like your modem only supports v4, and it gives you a tunnel to reach ipv6-only sites. It's not the same as OpenVPN.

Any modern ISP will do proper prefix delegation.

ow is a changing prefix handled in OpenVPN...?

That, and the 'rd' thing.
And me not being able to test because of a broken ISP

But even if it would work in the future, how is a changing prefix handled in OpenVPN...? Netgate hasn't shown much interest in fixing that situation even in general.

I will see if pfsense plus 26 is any different, and if the patches still apply cleanly. If not, I'll rework them.

Did you not read this whole thread?

I did - but sure enough, I wasn't actually reading what you were saying.
This threw me off track :
This is what I see right now on the OpenVPN server settings page :

Btw : I'm using pfSense Plus 26.03.

For a reason yet to be determined, you don't have the "IPv6 Tunnel Type" selection pull down ?
I could select 'Tracking' there, select the to be tracked IPV6 interface, and the prefix ID.

In the past, I was asking the same question as you : why can't I assign my own GUA type IPv6 to my OpenVPN server clients ?
Hardcoding a 2xxxxx......, using a /64 prefix from my ISP is a bad idea, as it can change any time.

I wasn't aware that this had changed - dono when ...

Then there is my "ISP IPv6 issue" : my ISP says it has a /56 for me. Great.
Or, pfSense can obtain only one ( 1 ) /64 and that's it. This is a known ISP router-box bug. So only my LAN uses IPv6, I can't assign other prefixes to other local networks.
I had to put "can my OpenVPN server also do IPv6" question on a side track.
This means also I couldn't even test your patches

Btw : pfSense does accept pull requests.

@TheGushi said in OpenVPN with ipv6 delegated prefix:

I also don't know why people question your desire to put "real" ipv6 addresses on your openvpn subnet. That's how ipv6 works, it's all assumed to be globally routable addresses.

That's my opinion also. I've GUA's avaible, so why not using them ?
There is something else I do know : I'm 'contaminated' with the IPv4 way of thinking, which means - for me - that how I should see and use IPv6 isn't probably correct. For some, I admit, stupid not founded reason, I don't like these fxxxxx IPv6 address. I prefer using DHCPv6 distributing GUA out of a prefix etc.

The patch affects three files -- I would make backups of them and if for any reason the patch doesn't apply cleanly, don't try to use it, copy the files back into place. Here's what I did while testing to back them up:

cp /etc/inc/openvpn.inc /etc/inc/openvpn.inc.orig
cp /usr/local/www/vpn_openvpn_server.php /usr/local/www/vpn_openvpn_server.php.orig
cp /etc/rc.newwanipv6 /etc/rc.newwanipv6.orig

I was also asking for that feature. It was not available. If you go look in your pfsense machine, you won't find the things in the screenshot that I posted (they only exist on my pfsense plus box).

I came up with a patch for PFSense that does what I need (and what you are asking for).

Maybe the PFsense authors will accept it and put it in a future version.

I also don't know why people question your desire to put "real" ipv6 addresses on your openvpn subnet. That's how ipv6 works, it's all assumed to be globally routable addresses.

said in OpenVPN with ipv6 delegated prefix:

Have a look at the official OpenVPN (server) manual, maybe there are special commands/settings to be used in the "Custom options" so that the OpenVPN server, a bit like what a DHCPv6 LAN server does when you use "Tracking" maybe there is a mechanisme for that ?

as I wasn't aware of this :

so the OpenVPN server can obtain a IPv6 prefix from 'upstream' ...
I never tested this (wasn't even ware that it was possible) ...

I plan to re-test that it applies cleanly when I'm safely home and can upgrade to 26.03 as well.

https://redmine.pfsense.org/issues/16822

I've come up with a patch to do what I want to do. I've tested it and ip6.me now shows a separate prefix from my comcast-delegated segment, and the admin UI lets me configure this thusly:

Is there some way I can submit this patch to the Netgate folks?

@Gertjan said in OpenVPN with ipv6 delegated prefix:

Do you want to 'expose' connected OpenVPN client to the Internet ?

Absolutely. The remote clients connected via OpenVPN should behave the same like local (except their higher latency and lower speed). I need this for some VoIP stuff because some VoIP servers hosted by the ISP are available through the network which is managed by this pfSense only.