OpenVPN with ipv6 delegated prefix
-
@Gertjan I'm away from home right now. Hitting the upgrade button on a faraway router didn't feel wise :)
I will see if pfsense plus 26 is any different, and if the patches still apply cleanly. If not, I'll rework them.
-
@Gertjan I think, I have read that this doesn't work like that, maybe it is related to "6rd", whatever that is.
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.
-
@Bob.Dig said in OpenVPN with ipv6 delegated prefix:
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
-
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.
-
@TheGushi said in OpenVPN with ipv6 delegated prefix:
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.
-
@Bob.Dig What exactly is not working that good in PFSense in general?
-
@TheGushi A delegated prefix changing. For me, WAN is down for a long time and clients like Windows will still using the old prefix.
-
@Bob.Dig Okay, so...what I think you're talking about here is this:
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.
-
@TheGushi said in OpenVPN with ipv6 delegated 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.
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.
-
@Bob.Dig If other routers work better for you, it would be interesting to see what works differently. PFSense is very configurable so you'd need to know what's happening differently under the hood.
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.
-
I haven't read through everything but would like to share some info.
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.
-
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
-
@marcosm said in OpenVPN with ipv6 delegated prefix:
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.
-
See
DeprecatePrefix:
https://man.freebsd.org/cgi/man.cgi?query=radvd.confThe radvd service gets shutdown then started indirectly via
/etc/rc.newwanipv6(which gets called by dhcp6c). -
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?
