IPv6 support for Captive Portal planned?
-
Since 2011 Pfsense startet with IPv6 support. Already then some early movers recognized that CP doesn't support IPv6. In the meantime IPv6 begins to become standard mostly as dual stack. Concerning the statistics Germany, Switzerland have 25%, Begium 48% and USA 19% IPv6 traffic already.
By what release is IPv6 support planned?
In a first step it's enough to search DNS and derive to the login page with IPv4. But after successful login IPv6 should be supported as soon as possible. In a further step IPv4+IPv6 must be supported fully (DNS request, internal web server for login page).
Thank you for your answer.
-
first of: i have no clue about the plans for ipv6 support for CP
for me, ipv6 has too many downsides to even consider allowing it on my networks. (no, security is not one of those downsides)
the biggest issue for me is, that it doesn't solve anything (for me) & i have no issue's with v4:-
every cheap multi-wan environment will still need todo NAT, but instead of nat44, you'll do nat66.
-
there is a lot of crappy v6 "firmware' in numerous devices on the lan side: printers/voip phones/cell phones. officially almost all recent devices support v6; reality differs greatly
so the few "upsides" of v6, from an end-user/smallbusiness perspective isn't there. (atleast not for me)
-
-
It's not something that's on our immediate radar.
- every cheap multi-wan environment will still need todo NAT, but instead of nat44, you'll do nat66.
That's not quite true in the way you imply. One WAN will work without NAT, additional WANs can use NPt (not an overload style) – yes, it's NAT, but 1:1 for the whole prefix, so a large number of traditional overload PAT-type NAT issues would not be a problem there. While it's not ideal, it's not anything I'd consider being a blocker or an impedance to its use.
-
Not related to the Captive portal, but very IPv6:
Natting to the Captive Portal ? That's seems a very rare thing to me. The people (clients, probably strangers) want to get 'out' - not hosting servers etc behind a Captive Portal connection …
The BIG advantage of IPv6 that NAT will be pretty unneeded. I'm using IPv6 and with the help of some precise firewall rules, I can address my devices from the Internet right into my LAN.A simple rule like (see image) will allow my server (on the Internet, using rsync and its IPv6 only) to address my diskstation (NAS Synology) using also an IPv6 (only) on my LAN.
NO NAT rule involved !!
-
Thanks for your replies, but I didn't want to have general discussion about IPv6 sense and non-sense. Fact is that IPv6 is upcoming more and more and Pfsense should be ready in all areas. We have a hotel with captive portal for our guests. CP isn't ready and it doesn't support for IPv6 traffic. In this year we will get a full dual stack (IPv4/IPv6) from our provider. Sometime in the future our guest will ask about IPv6 support. IPv4 addresses will by more and more rare so that some day a part of the internet won't support IPv4 anymore.
The question is still: Is planned that CP will support IPv6 in the future?
-
Bring up this old post from 2016. Site still states Captive Portal does not not have IPV6 support. are there any plans now to support IPV6?
-
I also have a hotel here, pfSense, and my LAN is fully dual stack for a couple of years now.
There are days, weeks, even months where there was more IPv6 traffic compared to IPv4.
But, today, mid octobre 2025, I don't recall ever see one client asking me why my portal doesn't support 'IPv6'.
More serious : I even doubt that I saw a client this year who knew what 'IPv6' or 'IPv4' is. That one person that didn't ask the reception about IPv6 didn't even bother : he connected to the portal over IPv4, fired up his "IPv6 aware VPN" connection and surfed away using IPv6 over my "IPv4 only" network ^^So, imho, no, IPv6 yet isn't a show stopper.
I already feel sorry for the guy @netgate who gets the mission to implement that one.
Btw :
@Enrica_CH said in IPv6 support for Captive Portal planned?:
IPv4 addresses will by more and more rare so that some day a part of the internet won't support IPv4 anymore.
That didn't age well ^^
Since 2016, there are no more 'free' IPv4 left, and still, IPv4 is still pretty mandatory everywhere.
Tens of thousand of IPv4 devices can access the internet just fine over just one ISP IPv4.
Most IPv6 aware ISP don't implement IPv6 - the prefix part, very well. Miost of them can give you a IPv6/128, but a prefix ? euh, oh, "we call you back".
Yes, IPv4 will fade out in the future. That's fact. Some one who starts to admin a pfSense today, and this person is 20 years old, then maybe he will see the end of 'IPv4' when he finishes his IT career ... -
We may be a relatively niche case as we have multiple routed subnets behind our captive portal. This means we can't tie clients to mac addresses. So I wonder how a captive portal would deal with a dual-stacked client, as logging in over IPv4 gives no information as to the IPv6 address that should be allowed (and vice-versa)?
Also, how would it handle privacy addressing where the client might rotate its IPv6 addresses? -
@anakha32 said in IPv6 support for Captive Portal planned?:
Also, how would it handle privacy addressing where the client might rotate its IPv6 addresses?
Exactly the same way as a client that decides to 'change it's IPv4' : it (the user) has to re login again.
Normally, this shouldn't happen, as devices 'should' use DHCP and or DHCPv6, so the DHCP and DHCOPv6 server decide what IP is leased to what client.
If devices don't use DHCPv6 (like SLAAC ?) and attribute themselves an local IPv6 like fe80:::..whatever then they should stick with it.Btw : your case : routers in the captive portal's network 'path' means the captive portal (pfSense) can't obtain the MAC address of the client - it will only 'see' the routers MAC address. That will limit somewhat the handling of the portal session, as there will be just one unique ID : the IPv4. And yes, the portal (pfSense) has no way to link that IPv4 to another IPv6 that also popped up in the network. With the MAC, and the incoming IPv6 packets, that relation would exist.
( all very afaik here ^^)The day IPv6 becomes relavant for the pfSEnse captive portal, chances are that you have to KIS this situation :
@anakha32 said in IPv6 support for Captive Portal planned?:have multiple routed subnets behind our captive portal.
KIS : keep it simple => make it more simple : one portal interface with one big switch and loads of APs all over the place and no more routers.
If that's possible for you of cours.
Btw : for my own curiosity : why placing routers on the portal network ?Also : throw this "rfc8910" into the forum search button.
I'm using it for over a year now, and make it makes the portal working 'even better' : as soon as a DHCPv4 request is executed by the client, it will :
a) knows there is a portal in play.
b) where to go so the user can login with a browser.The beauty of the solution proposed on this forum : no need to patch files. Just 'add' a file 'somewhere' and instruct ISC DHCP or kea to implement a DHCP option. Everything is detailed.
True : if the device uses (only) SLAAC (IPv6) ... then things will continue to break (not work) again ...@anakha32 said in IPv6 support for Captive Portal planned?:
privacy addressing
The real privacy ?
That's like : not to be seen when to use the public road ? Easy : don't go out, don't use the public road. Stay inside (or use an F35 as these seem to be pretty stealthy ^^)
Internet is the same thing : if privacy means anything, don't use it. Period.
If you use it, know that most traffic is TLS these day, so your data or content can't be seen.
For the more paranoid ones among us :
activate the portals session first.
the fire up your VPN or onion browser.
and you'll be pretty NSA save. -
@Gertjan said in IPv6 support for Captive Portal planned?:
@anakha32 said in IPv6 support for Captive Portal planned?:
have multiple routed subnets behind our captive portal.
KIS : keep it simple => make it more simple : one portal interface with one big switch and loads of APs all over the place and no more routers.
If that's possible for you of cours.
Btw : for my own curiosity : why placing routers on the portal network ?I'm part of a team that runs the network for a large university. The core of the network is all routed to limit the blast radius of problems. Each building has its own router with various networks on, including the guest wireless. But it makes sense just to have one captive portal box (pair), so all 300ish building subnets are routed through that.
Perhaps one day there will also only be one wireless system in the university. At which point tunnelling all the guest wireless traffic back to one point might be feasible and the guest wireless could become one big subnet.
