Captive portal: IPv6 support by swhite2 · Pull Request #9745 · opnsense/core

swhite2 · 2026-02-06T08:55:53Z

- Show IPv4 and IPv6 addresses in IP Address column - Aggregate traffic statistics across all IPs for a session - Add tooltip to display full IP addresses when truncated - Update accounting to include traffic from all associated IPs

…tack support - Resolved conflicts in captiveportal.inc: Use upstream's getValues() method while keeping IPv6 rules - Resolved conflicts in AccessController.php: Merged upstream's hostwatch dump with our IPv6 NDP fallback - Resolved conflicts in clients.volt: Use upstream's zone selection placement while keeping tooltip initialization - Resolved conflicts in pf.py: Preserved IPv6 protocol handling (0x86dd) and accounting methods - Resolved conflicts in db.py: Merged our aggregation logic with upstream's prev_* fields for counter reset detection - Resolved conflicts in cp-background-process.py: Adapted dual-stack MAC handling to use upstream's helper methods All IPv6 dual-stack functionality is preserved while incorporating upstream improvements.

fichtner · 2026-02-06T08:59:02Z

+        $backend = new Backend();
+        $backend->configdRun('template reload OPNsense/IPFW');
+        $backend->configdRun("ipfw reload");


is this side effect a good idea? feels a bit too clever :)

I expected comments here ;)

To be honest this was the quickest win here, the IPFW reload is a requirement though, and missing since the re-introduction of it and I didn't spot any other obvious hooks in the right place.

for context: the spot where this code resided previously was cleaned up in d8519a0

Looks duplicate now, as in the following line both dnctl and ipfw are triggered when no argument is specified:

core/src/etc/inc/filter.inc

Line 179 in 36b17ad

mwexecf('/usr/local/opnsense/scripts/shaper/start.sh');

@AdSchellevis Coming back to this as it's related to #9902.. the start.sh script does not trigger the template generation for https://github.com/opnsense/core/blob/master/src/opnsense/service/templates/OPNsense/IPFW/rc.conf.d, which means that configuring a zone in a clean install will likely not kickstart ipfw until a reboot.

In this case I'd opt for

$backend->configdRun('template reload OPNsense/IPFW');

To remain in here.

fichtner · 2026-02-06T14:01:49Z

-        <label>Allow multiple client IPs</label>
-        <help>Allow a connecting client to use multiple IPs (bound to the same MAC). For IPv4, these can be virtual IPs on the client. For IPv6, this option is needed for maximum compatibility because a client may actively use multiple IPv6 addresses.</help>
+        <label>Client roaming</label>
+        <help>Allow a connecting client to use multiple IPs (bound to the same MAC) over the course of its session. For IPv4, these can be virtual IPs on the client. For IPv6, this option is needed for maximum compatibility because a client may actively use multiple IPv6 addresses.</help>


strictly speaking the more common term is "alias" for an extra address (as per ifconfig). Both could still be confusing. Perhaps we can remove the IPv4 explanation or change it to a minor note "This also affects IPv4."

Wouldn't that also allow login from multiple IPs? Didn't we have a setting for that? Concurrent something?

(if it's strictly tied to the MAC/DUID that's something else and please ignore me)

"roaming" keys clients (with IP aliases) to a MAC address, if they connect from a different device the "concurrent user logins" setting still applies, different MAC.

agoodkind · 2026-02-22T16:15:08Z

Thanks for taking this over!

AdSchellevis

@swhite2 I think we're almost there, missed a couple of spots we discussed last time and added one question about ipv4 on dual stack nets.

AdSchellevis · 2026-03-07T09:06:38Z

+
+session_ips = {args.ip_address}
+if args.roaming:
+    session_ips = db.update_roaming_ips(args.zoneid, response.sessionId, arp.get_all_addresses_by_mac(arp_entry['mac']))


as discussed we likely better only add the connected address and let the background process take care of the rest.

AdSchellevis · 2026-03-07T09:07:23Z

 [allow]
 command:/usr/local/opnsense/scripts/captiveportal/allow.py
-parameters:--zoneid=%s --username=%s --ip_address=%s --authenticated_via=%s
+parameters:--zoneid=%s --username=%s --ip_address=%s --authenticated_via=%s --roaming=%s


when roaming isn't relevant, we can ditch it from here as well.

AdSchellevis · 2026-03-07T09:10:16Z

-                {% if conf_key == intf_tag and conf_inf.ipaddr and conf_inf.ipaddr != 'dhcp' %}
-                    {% do item.update({'interface_hostaddr':conf_inf.ipaddr}) %}
+                {% if conf_key == intf_tag %}
+                    {# prefer IPv6 if available, fallback to IPv4 #}


what happens with dual stack and an ipv4 only client here?

This makes IPv4 and IPv6 portal entry points behave consistently, fixes proxied client IP detection, and lets roaming sessions discover IPv6 addresses quickly enough to authorize privacy and secondary addresses on the same client.

agoodkind · 2026-03-12T03:54:46Z

@agoodkind If you have the setup... care to give this a spin?

I had some free time and did a matrix of testing and made a PR that tries to address all of @AdSchellevis comments along with bugs I discovered: #9927

This restores best-effort sibling address authorization at login for already-known addresses on the same MAC, while keeping the background reconciliation path as the source of truth for later convergence and cleanup.

…lockups

…-dual-stack-support

…-dual-stack-support Follow up for dual-stack captive portal authorization in `CaptivePortal`

agoodkind · 2026-03-13T04:56:05Z

Tested with my setup against 9df582a

Setup

opnsense-dev

Captive Portal test zone on lan
Portal hosts:
- IPv4: 10.240.240.1:8000
- IPv6: 3d06:bad:b01:240::1:8000
Standard outbound NAT66 for 3d06:bad:b01:240::/64
DNS64 enabled in Unbound
dns64prefix: 3d06:bad:b01:2464::/96
radvd advertises nat64prefix 3d06:bad:b01:2464::/96
DHCPv4 option 108 present on lan

ubuntu-vm-test

Single NIC behind opnsense-dev
systemd-networkd
Address types exercised:
- IPv4 DHCP
- DHCPv6 IA_NA /128
- SLAAC / privacy /64
- extra temporary /64
Two guest modes:
- dual-stack
- IPv6-only preferred (IPv6OnlyMode=yes)

Current behavior

The login address works immediately.

Sibling addresses do not always work immediately on current upstream. Addresses that are already visible to the firewall may still need the background reconciliation pass before they are consistently usable.

Matrix

Case	Result	Notes
IPv4-only pre-auth	Pass	Redirects to IPv4 portal host
IPv4-only auth via IPv4	Pass	IPv4 egress works immediately
Dual-stack pre-auth via IPv4	Pass	Redirects to IPv4 portal host
Dual-stack pre-auth via IPv6	Pass	Redirects to IPv6 portal host
Dual-stack auth via IPv4, same IPv4 address	Pass	Login address works immediately
Dual-stack auth via IPv4, DHCPv6 `/128` sibling, cold cache	Delayed	Not immediately*
Dual-stack auth via IPv4, already-known IPv6 siblings, warm cache	Mixed	Better once visible, not consistently immediate
Dual-stack auth via IPv6, same DHCPv6 `/128` address	Partial	First request can still see one `302`, retry works
Dual-stack auth via IPv6, IPv4 sibling, cold cache	Delayed	Not immediately*
Dual-stack auth via IPv6, already-known IPv4 and IPv6 siblings, warm cache	Mixed	Better once visible, not consistently immediate
IPv6-only preferred pre-auth	Pass	Redirects to IPv6 portal host
IPv6-only preferred auth via DHCPv6 `/128`	Partial	Same narrow first-request race as above
IPv6-only preferred auth via privacy / SLAAC `/64`	Pass	Immediate post-auth IPv6 egress worked
NAT64 / DNS64 / PREF64 after auth	Pass	Synthesized `3d06:bad:b01:2464::101:101` returned a real HTTP response
Multi-address IPv6 convergence	Pass	Newly observed sibling addresses join later through background reconciliation

Main takeaway

Current upstream is usable for the core portal flow, but it still has a convergence model rather than an immediate warm-start model.

The address used for login works immediately. Other addresses on the same client join later as they become visible to the firewall and the background reconciliation loop processes them.

The narrowest remaining rough edge is the DHCPv6 /128 source case, where the first immediate post-login request can still receive one redirect before the next request succeeds.

*Sibling addresses usually became usable within about 5 to 12 seconds, which lined up with the 5 second background reconciliation loop plus the time needed for the address to become visible in neighbor discovery.

agoodkind · 2026-03-13T05:04:47Z

        <id>zone.servername</id>
        <label>Hostname</label>
        <type>text</type>
        <help><![CDATA[Hostname (of this machine) to redirect login page to, leave blank to use this interface IP address, otherwise make sure the client can access DNS to resolve this location. When using a SSL certificate, make sure both this name and the cert name are equal.]]></help>


Maybe could change to:

Hostname to redirect the login page to. Leave blank to use the interface IP address. When using an SSL certificate, the hostname and certificate name must match. Note: For IPv6-only client compatibility, either set a hostname with both A and AAAA records, or ensure the selected interface has a static IPv6 address configured. If only a dynamic DHCPv6 address is present and no hostname is set, IPv6-only clients may be redirected to an IPv4 address they cannot reach.

Suggested change

<help><![CDATA[Hostname to redirect the login page to. Leave blank to use the interface IP address. When using an SSL certificate, the hostname and certificate name must match. Note: For IPv6-only client compatibility, either set a hostname with both A and AAAA records, or ensure the selected interface has a static IPv6 address configured. If only a dynamic DHCPv6 address is present and no hostname is set, IPv6-only clients may be redirected to an IPv4 address they cannot reach.]]></help>

I advice to avoid HTML inside language strings as this will break during translation.

Fair. I took out the HTML formatting in the string suggestion

swhite2 · 2026-03-13T12:56:15Z

@agoodkind Thanks for your further testing. Your results seem to align with what is to be expected given the constraints. After some further discussion internally, the best strategy to address the rather complicated lighty template seems to be to stop guessing for IPv6 addresses (which are going to be static less often in comparison to IPv4 anyway) and require that a user sets a proper hostname + associated AAAA records (and possibly DNS64 support in Unbound) to make IPv6 work.

agoodkind · 2026-03-15T18:46:54Z

@agoodkind Thanks for your further testing. Your results seem to align with what is to be expected given the constraints. After some further discussion internally, the best strategy to address the rather complicated lighty template seems to be to stop guessing for IPv6 addresses (which are going to be static less often in comparison to IPv4 anyway) and require that a user sets a proper hostname + associated AAAA records (and possibly DNS64 support in Unbound) to make IPv6 work.

Thanks for the follow-up. I understand the appeal of simplifying the template, but requiring a hostname + AAAA for IPv6 captive portal to function at all would be quite a gap IMO. Although it is true that most network admins should set up some type of hostname to handle this, I still feel it is a gap.

track6 is the documented way to deploy DHCPv6-PD on LAN, DHCPv6-PD is required by RFC 7084 for CE routers, and RIPE-690 documents it as the standard operator practice for prefix assignment to end-users.

For example, I've encountered two different ISPs where you are required to use DHCP-PD otherwise the traffic won't route (AT&T Fiber Business, and Webpass Business). A captive portal that silently falls back to an unreachable IPv4 address in that configuration is a real bug, not a corner case.

The fix itself is fairly contained: runtime address resolution for track6 interfaces The configd template system was designed around config.xml, which holds static values. With track6, the LAN address is runtime-derived from DHCPv6-PD and isn't in config.xml at all. The web GUI (https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/webgui.inc#L36), Unbound (https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/unbound.inc#L45), and OpenSSH (https://github.com/opnsense/core/blob/master/src/etc/inc/plugins.inc.d/openssh.inc#L44) solved this same problem via newwanip hooks and PHP-side config regeneration (#5966). The captive portal lighttpd config uses the Jinja2 template system instead, so the address has to enter the template somehow. I opened a PR with both: #9973

AdSchellevis · 2026-03-15T19:09:28Z

    {
+        $clientAddress = $this->request->getClientAddress();
+        $forwardedFor = $this->request->getHeader('X-Forwarded-For');
+        $realIp = $this->request->getHeader('X-Real-Ip');


Can we please just go back to the original situation, I have a very strong feeling we're trying to fix an edge case while introducing new security concerns in the process. It's debatable if by default any of these headers should be processed, but since that's already the case (introduced a very long time ago a7033f2), let's try not to increase the impact so we can discuss improvements on this topic in a separate ticket.

AdSchellevis · 2026-03-15T19:09:53Z

                                $userName,
                                $clientIp,
-                                $authServerName
+                                $authServerName,


Suggested change

$authServerName,

$authServerName

AdSchellevis · 2026-03-15T19:19:06Z

+        # Clear pre-auth states so newly authorized sibling addresses can use the updated table match immediately.
+        subprocess.run(['/sbin/pfctl', '-k', f'{address}'], capture_output=True)
+        wildcard = '::/0' if PF._is_ipv6(address) else '0.0.0.0/0'
+        subprocess.run(['/sbin/pfctl', '-k', wildcard, '-k', f'{address}'], capture_output=True)


this looks rather suspicious and may result in unexpected locked sessions to already accepted destinations.

Strip IPv4 runtime resolution (unnecessary since config.xml has the static address) and preserve upstream PR opnsense#9745 template structure. Only two targeted changes on top of swhite2's branch: 1. Runtime IPv6 resolution via get_interface_address.php for track6 interfaces, falling back to conf_inf.ipaddrv6 for static configs 2. Bracketed IPv6 regex fix in [::] socket blocks so redirurl is not truncated at the first colon

…e pf state kill, backend listening op IPv4 only so adjust AccessController logic

The host-match regex ([^:/]+) in the IPv6 lighttpd socket blocks truncates bracketed IPv6 literals at the first colon, producing a broken redirurl (e.g. [2601/ instead of [2606:4700:4700::1111]/). Change the capture group to (\[[^\]]+\]|[^:/]+) so a full bracketed literal is matched first, falling back to the original pattern for IPv4 addresses and hostnames. Missed in: 369630d (Captive portal: IPv6 support, opnsense#9745) See also: opnsense#9973

The host-match regex ([^:/]+) in the IPv6 lighttpd socket blocks truncates bracketed IPv6 literals at the first colon, producing a broken redirurl (e.g. [2601/ instead of [2606:4700:4700::1111]/). Change the capture group to (\[[^\]]+\]|[^:/]+) so a full bracketed literal is matched first, falling back to the original pattern for IPv4 addresses and hostnames. Missed in: 369630d (Captive portal: IPv6 support, #9745) See also: #9973

Co-authored-by: Alex Goodkind <alex@goodkind.io> (cherry picked from commit 369630d) (cherry picked from commit 5b07e09) (cherry picked from commit 2ac18ce) (cherry picked from commit cff0e8d) (cherry picked from commit 6f00e1e)

This reverts commit 497ed54. Revert for the time being since 26.1.5 doesn't force a reboot.

Co-authored-by: Alex Goodkind <alex@goodkind.io> (cherry picked from commit 369630d) (cherry picked from commit 5b07e09) (cherry picked from commit 2ac18ce) (cherry picked from commit cff0e8d) (cherry picked from commit 6f00e1e) (cherry picked from commit da2c0bd) (cherry picked from commit e5effd4)

agoodkind and others added 6 commits January 2, 2026 18:16

Merge remote-tracking branch 'origin/master' into captive-portal-ipv6

6d0c140

captive portal: WIP for IPv6 support

9937de0

Merge remote-tracking branch 'origin/master' into captive-portal-ipv6

3fe3500

captive portal: limit hostwatch output and other small changes

ac2dc26

swhite2 requested review from AdSchellevis, Monviech and fichtner February 6, 2026 08:55

swhite2 self-assigned this Feb 6, 2026

swhite2 marked this pull request as draft February 6, 2026 08:56

fichtner reviewed Feb 6, 2026

View reviewed changes

clean up ipv6 localhost usage

e90249c

fichtner reviewed Feb 6, 2026

View reviewed changes

Comment thread src/opnsense/mvc/app/models/OPNsense/CaptivePortal/CaptivePortal.xml Outdated

comment not relevant anymore

f788e18

swhite2 mentioned this pull request Feb 6, 2026

Add IPv6 dual-stack support to Captive Portal #9575

Closed

swhite2 added 2 commits February 6, 2026 12:02

shorten this

9b545e2

captive portal: rename virtual IPs to 'roaming'

219e076

fichtner reviewed Feb 6, 2026

View reviewed changes

Monviech reviewed Feb 6, 2026

View reviewed changes

Comment thread src/etc/inc/plugins.inc.d/captiveportal.inc

captive portal: fix and clean up session handling

d1ee6b7

swhite2 marked this pull request as ready for review February 11, 2026 13:50

swhite2 added 5 commits February 11, 2026 15:59

captive portal: simplify hostdiscovery output handling

43675dd

captive portal: no scope stripping needed

8be14b6

in fact, this documents itself

c6d526f

captive portal: some more cleanups

fe4748b

remove unused code

8297c7d

AdSchellevis force-pushed the master branch from b32c61a to 6cfd38c Compare February 12, 2026 09:02

AdSchellevis requested changes Feb 21, 2026

View reviewed changes

swhite2 requested a review from AdSchellevis March 4, 2026 09:06

AdSchellevis requested changes Mar 7, 2026

View reviewed changes

Finish captive portal dual-stack authorization flow.

5b85f46

This makes IPv4 and IPv6 portal entry points behave consistently, fixes proxied client IP detection, and lets roaming sessions discover IPv6 addresses quickly enough to authorize privacy and secondary addresses on the same client.

agoodkind mentioned this pull request Mar 12, 2026

Follow up for dual-stack captive portal authorization in CaptivePortal #9927

Merged

agoodkind and others added 7 commits March 11, 2026 21:57

Warm-start captive portal roaming expansion.

5568a41

This restores best-effort sibling address authorization at login for already-known addresses on the same MAC, while keeping the background reconciliation path as the source of truth for later convergence and cleanup.

captive portal: ditch address fetch in allow.py to prevent potential …

5114d1e

…lockups

add accounting as well

cf48c5a

last bits of allow.py

bc7a9ed

Merge branch 'captive-portal-ipv6' into agoodkind/captive-portal-ipv6…

1c92d4f

…-dual-stack-support

Merge pull request #9927 from agoodkind/agoodkind/captive-portal-ipv6…

5ad965a

…-dual-stack-support Follow up for dual-stack captive portal authorization in `CaptivePortal`

ditch ndp from arp source

9df582a

agoodkind reviewed Mar 13, 2026

View reviewed changes

agoodkind mentioned this pull request Mar 15, 2026

Captive portal: fix track6 IPv6 redirect host and bracketed redirurl #9973

Closed

AdSchellevis requested changes Mar 15, 2026

View reviewed changes

captive portal: trim IPv6 address fetch logic in zone template, remov…

d43718b

…e pf state kill, backend listening op IPv4 only so adjust AccessController logic

AdSchellevis approved these changes Mar 16, 2026

View reviewed changes

swhite2 merged commit 369630d into master Mar 16, 2026

swhite2 deleted the captive-portal-ipv6 branch March 16, 2026 08:46

agoodkind mentioned this pull request Mar 17, 2026

Captive portal: fix bracketed IPv6 literal in redirurl regex #9981

Merged

fichtner added a commit that referenced this pull request Mar 24, 2026

Revert "Captive portal: IPv6 support (#9745)"

c102de2

This reverts commit 497ed54. Revert for the time being since 26.1.5 doesn't force a reboot.

Lukas290507 mentioned this pull request Apr 12, 2026

When upgrading to 26.1.6, the function of captiveportal not authenticating addresses and subnets in this list becomes ineffective #10124

Closed


	<help><![CDATA[Hostname to redirect the login page to. Leave blank to use the interface IP address. When using an SSL certificate, the hostname and certificate name must match. Note: For IPv6-only client compatibility, either set a hostname with both A and AAAA records, or ensure the selected interface has a static IPv6 address configured. If only a dynamic DHCPv6 address is present and no hostname is set, IPv6-only clients may be redirected to an IPv4 address they cannot reach.]]></help>

Conversation

swhite2 commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

agoodkind commented Feb 22, 2026

Uh oh!

AdSchellevis left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

agoodkind commented Mar 12, 2026

Uh oh!

agoodkind commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Setup

Current behavior

Matrix

Main takeaway

Uh oh!

agoodkind Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

agoodkind Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swhite2 commented Mar 13, 2026

Uh oh!

agoodkind commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

swhite2 commented Feb 6, 2026 •

edited

Loading

agoodkind commented Mar 13, 2026 •

edited

Loading

agoodkind Mar 13, 2026 •

edited

Loading

agoodkind Mar 14, 2026 •

edited

Loading

agoodkind commented Mar 15, 2026 •

edited

Loading