Project

General

Profile

Actions

Feature #1831

open

Captive portal IPv6 support

Added by Chris Buechler over 12 years ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
09/01/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Plus-Next
Release Notes:

Description

Captive portal needs IPv6 support. ipfw fwd doesn't function with IPv6 last I heard, amongst other things that need work here for v6.


Files

CaptivePortal_IPv6.zip (42.3 KB) CaptivePortal_IPv6.zip Cyrill B, 12/31/2012 08:59 AM
CaptivePortal_IPv6_v2.zip (46.3 KB) CaptivePortal_IPv6_v2.zip Cyrill B, 12/31/2012 09:24 AM
cp-ipv6-ugly.diff (2.58 KB) cp-ipv6-ugly.diff Jim Pingle, 05/25/2022 07:37 AM
Actions #1

Updated by Thomas NOEL over 12 years ago

Hello,

I'm very interrested by this topic (IPv6 for CP). Do you have any plan or any schedule for this development ? If your team is ready to work on this, is a targeted donation is possible (and does it help) ?

Actions #2

Updated by Chris Buechler over 12 years ago

this is, like everything with IPv6, targeted for 2.1. This is likely the single most complex and time consuming piece (actually several pieces directly related to this) of anything outstanding with IPv6. We're seeking donations for IPv6 work in general, and specifically if you could put something towards this that would be very helpful. Please email me to discuss details - cmb at pfsense dot org.

Actions #3

Updated by Ermal Luçi over 12 years ago

For CP on IPv6 to work ipfw tables need to be tought about v6 addresses and
ipfw forward at layer2 needs to be coded for v6.

Actions #4

Updated by Chris Buechler about 12 years ago

  • Target version changed from 2.1 to 2.2

there is a lot involved here, people will expect to auth both v4 and v6 IPs in a single shot which complicates everything. Our HSIA customers have indicated it's not an important feature in the immediate (or even foreseeable in some cases) future, and we're on too tight a schedule for 2.1 to get this done by then, so pushing to 2.2.

Actions #5

Updated by Cyrill B about 11 years ago

  • File 0001-MFC-r232865-r232868-and-r233478.patch added

MFC r232865, r232868 and r233478 added ipfw support for IPv6 tables in stable. To apply the changes the CaptivePortal multi instance patch (CP_multi_instance_ipfw.diff) may also require a few changes.

Actions #6

Updated by Cyrill B about 11 years ago

... and CP_speedup.diff also.

Actions #7

Updated by Ermal Luçi about 11 years ago

I think ipv6 fwd support on ipfw is not on 8.3, though i might be wrong!
And you forgot to attach as well.

As usual github pull requests are better in general :)

Actions #8

Updated by Cyrill B about 11 years ago

  • File CP_speedup.diff added

Yes, I believe there are only partial patches available for ipv6 fwd support for stable/8 such as http://www.freebsd.org/cgi/query-pr.cgi?pr=117214.
I didn't yet put any patches on github as they cannot be applied individually and they would break the current implementation.

So those modifications / patches are just tiny steps until full support. For now I have also modified and attached the CP_speedup.diff to support IPv6. The patch applies after the above 0001-MFC-r232865-r232868-and-r233478.patch (IPv6 tables support) which by the way applies to 8.3 release.

Before any of those patches can be included at least the context switching (CP_multi_instance_ipfw.diff) will have to be migrated and there are also changes required to the pfSense php module (or the ipfw binary will have to be used again). And of course to make everything work ipv6 fwd support will be needed.

Actions #9

Updated by Cyrill B about 11 years ago

I'll just add this here so that it doesn't get lost:
Add IPv6 support to 'pfSense_ip_to_mac' function https://github.com/bsdperimeter/pfsense-tools/pull/57

Actions #10

Updated by Cyrill B about 11 years ago

  • File php53-pfSense-module.patch added
  • File filterdns.patch added

Those patches make the required changes to the php53-pfSense-module and the filterdns ports.

Actions #11

Updated by Cyrill B about 11 years ago

  • File cp_ipv6.png added

IPv6 here we are! There's still some cleanup to be done but other than that it is working.

Still todo:
- add ipv6 to the default ipfw rules
- captiveportal php code needs some adjustments (e.g. 32bit netmask)

Actions #12

Updated by Cyrill B about 11 years ago

I assume there won't be any major changes anymore to 2.1 thus this feature will be integrated in 2.2? So I can either upload the patches here in a zip file or on github and create a pull request. What do you prefer?

I could also provide a working iso if someone wants to test it.
Maybe an admin can also cleanup my mess here and remove the files that I have previously attached, some of them required further modifications.

Actions #13

Updated by Chris Buechler about 11 years ago

Go ahead and attach it here for now, though that will almost certainly require some updating to merge cleanly post-2.1, we don't want any v6 CP in 2.1. This likely will require a lot of work to be usable in real world scenarios for a variety of reasons and that's not something we can support for 2.1. I'll remove the files attached to this point.

Actions #14

Updated by Chris Buechler about 11 years ago

  • File deleted (0001-MFC-r232865-r232868-and-r233478.patch)
Actions #15

Updated by Chris Buechler about 11 years ago

  • File deleted (CP_speedup.diff)
Actions #16

Updated by Chris Buechler about 11 years ago

  • File deleted (php53-pfSense-module.patch)
Actions #17

Updated by Chris Buechler about 11 years ago

  • File deleted (filterdns.patch)
Actions #18

Updated by Chris Buechler about 11 years ago

  • File deleted (cp_ipv6.png)
Actions #19

Updated by Cyrill B about 11 years ago

Attached is the zip file with the required patches. All files except for the patch captiveportal.inc.diff, which applies to the pfsense repository, are part of the pfsense-tools repository. Patches apply to the FreeBSD 8.3 sources and code in the master branch as of 2012-12-31.

If you just want to take a look at the code you can also do so on github on the ipv6_cp branch in my (pfsense) [1] and (pfsense-tools) [2] repositories. I also made an iso [3] for anyone that wants to do early testing of the IPv6 capability.

I only tested a few Captive Portal use cases (e.g no radius) which seemed to work quite nicely, however there are still a few remaining issues which include:
  • User needs to login / logout for IPv4 and IPv6 addresses
  • The ipfw filter rules allow communication between IPv6 link-local addresses
  • Captive Portal Settings GUI is not yet fully IPv6 compatible (e.g. only accepts IPv4 addresses under "Allowed IP Addresses")

[1]: https://github.com/bcyrill/pfsense/tree/ipv6_cp
[2]: https://github.com/bcyrill/pfsense-tools/tree/ipv6_cp
[3]: http://www.twinsquared.ch/bcyrill/download/get/pfsense/pfSense-LiveCD-2.1-DEVELOPMENT-i386-20121231-0540.iso

Actions #20

Updated by Cyrill B about 11 years ago

The required pfPorts patches were missing in the above archive.

Actions #21

Updated by Thomas B over 10 years ago

Great work, and Thanks Cyrill.

Unfortunately I found another bug in the code, while setting up the CP for v6 in my network.
Since I'm using a central RADIUS authentication, there is an error shown while going through the captive portal.

There is a response on from the pfsense appliance, which says "Fatal Error: Error in converting address in /etc/inc/radius.inc on line 210"

I'm running the setup with a virtual machine.

Hopefully we can fix that somehow?

Best wishes,

Thomas from Munich

Actions #22

Updated by Chris Buechler almost 10 years ago

  • Target version changed from 2.2 to Future
Actions #23

Updated by Martin Gollowitzer over 8 years ago

Hi,

I just stumbled over this ticket after trying to find the reason for IPv6 not working in my guest WiFi. Since IPv6 is becoming more and more important (my ISP has started to switch customers to DS-Lite already), I think this feature would really be a big step towards better IPv6 adoption. I am willing to even through a little bit of money towards anyone who gets this included in one of the upcoming versions. Unfortunately, I am not a developer myself, but I can of course help with testing (and reading code, which is by far easier than writing). Please let me know what else I can do.

Thanks,
Martin

Actions #24

Updated by Klaus Steinberger over 7 years ago

Hi,

I think this is an important issue, I would like to see it as early as possible in pfsense, as IPV6 is an important protocol at our site.

Actions #25

Updated by James Webb over 6 years ago

With the growing demand for IPv6 it is essential that this feature is implemented ASAP.
Do we have a timeline on when this would be completed?

Actions #26

Updated by Brandon Jackson over 5 years ago

Bump. Its 2018, how is this still a thing.

Actions #27

Updated by Flole Systems about 5 years ago

It's 2019 and guess what: This is still missing, while the fixes were apparently ready years ago....

Actions #28

Updated by A FL about 5 years ago

PHP RADIUS package (used for RADIUS authentication/accounting) is not IPv6 compatible, which is a captive portal dependency. That is one of the reasons why captiveportal does not support IPv6 yet.

If you want to contribute to this PHP package to implement IPv6, please feel free to do it : https://pear.php.net/package/Auth_RADIUS

Actions #29

Updated by Flole Systems about 5 years ago

Unfortunately that site is down. However, I've done some additional research and it seems like others simply use string datatype for IPv6 Addresses instead of IP-Address Datatype. Any reason why this wouldn't work here?

Actions #30

Updated by Mantas Mikulėnas about 5 years ago

Flole Systems wrote:

Unfortunately that site is down. However, I've done some additional research and it seems like others simply use string datatype for IPv6 Addresses instead of IP-Address Datatype. Any reason why this wouldn't work here?

Won't that mean the user will need to log in at least twice separately – once via IPv4 and once via IPv6? (Plus again every 10 hours if they have IPv6 tempaddr / 'privacy extensions' enabled.)

Actions #31

Updated by Flole Systems about 5 years ago

If authentication is based on IP Address yes, if it would be based on MAC Address then no.

If it's not MAC based then there are quite a few other issues like pfsense only seeing the IPv4 Address and not the IPv6 or vice versa. Of course when using MAC based authentication you can't have another router between client and pfsense but I think thats a limitation most people won't care about (another option would be to make it configurable to enable IP based authentication and add a note that doing so breaks IPv6 Support).

Actions #32

Updated by Jim Pingle almost 2 years ago

Now that Captive Portal has been migrated to pf this may be possible with some effort. If not we can always re-evaluate and move it forward again.

Adjusting the new pf rules for captive portal such that they also capture IPv6 traffic does lead the user to the portal page as expected and they can try to login, but it fails after that. See the attached ugly diff (could be optimized a lot, this was just a quick proof of concept).

A couple sticking points / random thoughts:

  • pfSense_ip_to_mac() from the PHP module doesn't find the MAC, possibly because it's only checking IPv4/ARP and not IPv6/NDP
  • Parts of the code that use the IPv4 address in certain ways (like anchor names) may need adjusted if an IPv6 address is not also valid in those contexts.
  • Probably lots of input and other validation would need adjusted to allow both families
  • If the user logs into the portal from one address family that's the IP address that will show in the CP database and pf tables/rules.
    • Ideally the user should not have to login twice for IPv4/6 but trying to discover the client addresses for both families could be error prone.
    • We can't rely on just forcing the user to the portal by a specific IP address family as with HTTPS logins could be using a hostname which could resolve to either one or both address families and the client will choose the one to use based on its own local configuration.
    • Checking both ARP and NDP for the client MAC might not be accurate if the client hasn't contacted the gateway from the other address family recently.
    • Could maybe have an option that is the opposite of disabling MAC filtering that does only MAC filtering (e.g. pass anything to/from the client MAC and not tied to any specific IP address/family)

Feel free to move the target farther forward if it turns out to be more trouble than expected.

Actions #33

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 22.09 to 22.11
Actions #34

Updated by Reid Linnemann over 1 year ago

  • Target version changed from 2.7.0 to Future
  • Plus Target Version changed from 22.11 to Plus-Next

Updated target versions as this is not in the body of work for 11/2022.

Actions

Also available in: Atom PDF