IPv6 changes aren't written to config.xml or dhcp6c.conf
-
I have spent the last several days following doc, blog posts, LLM suggestions, and trial and erroring IPv6 configuration on pfSense, and I'm starting to think the 2.8.1-release has some kind of unexpected state bug that I'm running into that renders IPv6 completely unusable. But as I am not the expert in what causes config to take, I thought I'd consult the experts here.
In a nutshell, the IPv6 changes I'm making aren't taking. Many times over, I've configured gateways, WAN and LAN interfaces, Firewall NAT, Firewall rules, DHCPv6 server, Router advertisements, and all I ever get in the /var/etc/dhcp6c.conf is the following:
interface em0 {
script "/var/etc/dhcp6c_wan_script.sh";
};Resaving and applying doesn't work. Restarting services doesn't work. Rebooting the pfSense box doesn't work. I've even reset pfSense to factory settings and have done it all again clean, still doesn't work.
The problem is neither upstream nor downstream from pfSense -- the problem is pfSense. Upstream, I have tried configuring IPv6 with two different ISPs, both AT&T fiber, and Cox cable modem -- same thing with both. I have successfully configured IPv6 with both ISPs in a matter of minutes by bypassing pfSense, and did it two different ways: first connecting a computer directly to these ISP modems, and also connecting a separate Wifi router directly to these ISP modems. No problems getting IPv6 up and running with either.
What is the magic that causes changes you make in the pfSense UI console to actually be saved and written to configuration files? I've run pfSense for about 8 years with never a single issue until two things this past week: 1) upgrading to 2.8.1-release and 2) trying to debug an issue which was due to improper IPv6 handling and discovering that there seems no way to reconfigure IPv6 on pfSense via the UI console. Is this a known bug? What do you have to do to get IPv6 related changes to be permanently saved?
Thanks so much for your help -- I was about to buy some new pfSense-running hardware, and this halted me in my tracks. I can't use it if there's no way to configure IPv6...I imagine there's a magic spell or ceremony that will help me find my way through.... :-D
Thanks, B
-
@brado7274 you would have to be more specific what exactly you enabled and what settings are not sticking.
I have IPv6 enabled on 2.8.1 and it works as expected for me, the settings are saved.- what type of hardware you run it on?
- had you IPv6 configured and working before the upgrade?
- what type of IPv6 configuration have you done for WAN?
- what DHCP server are you using, ISC DHCP or KEA?
The pfSense documentation has plenty of information about IPv6 configuration:
https://docs.netgate.com/pfsense/en/latest/interfaces/configure-ipv6.html
https://docs.netgate.com/pfsense/en/latest/network/ipv6/index.html -
@patient0 Thanks so much for the reply, and I appreciate the questions. Forgive me for sparing all the technical details on my first post -- that was intentional, b/c I thought the best approach was to distill the issue down to the core matter, which is how / when pfSense configuration changes are saved and written to configuration files. As mentioned, I've gone through docs, blog posts, and I've got 50+ pages (maybe slight exaggeration, but not by much) of LLM iterations of configuration settings tried. The issue seems to not be the settings themselves, but that it doesn't really matter what settings are made, they don't persist, or find their way to the supposed config files which drive service function. But I'll now add some details, and hopefully we can figure this out.
My hardware is a Protectli Vault FW6A, and I've been running since 2019 flawlessly until the past recent months. For years I've had Cox cable modem as my ISP, and earlier this year AT&T rolled out fiber in my area (March-ish). I acquired AT&T fiber and kept Cox, and ran multi-WAN in pfSense, and while I configured and tested WAN failover (and it worked fine), I opted to keep both WAN configs totally separate: no failover or load-balancing, no Gateway Groups, etc. Just two separate WANs, each associated with their own separate LAN. Here's how that shakes out on the Protectli Vault ports:
PORT - Interface Name
WAN - WAN_ATT
LAN - LAN_ATT
OPT1 - LAN_COX
OPT2 - WAN_COXIn the case of both WAN interfaces, the general idea:
- IPv4 Configuration Type: DHCP
- IPv6 Configuration Type: DHCP6
- DHCP6 Client Configuration: various options selected, but have experimented with all at one point.
In the case of both LAN interfaces, the general idea:
- IPv4 Configuration Type: Static IPv4 (with its own network range separate from the other LAN)
- IPv6 Configuration Type: Track Interface (to the associated WAN interface)
Firewall NAT -- Automatic outbound NAT
Firewall Rules- WANs: either auto-generated (depending on block options) or none
- LANs: both IPv4 and IPv6 allow associated LAN subnet to any
Services --> DHCPv6 Server (both LANs): Kea DHCP (note this was a switch made from ISC DHCP during debugging), enabled, registrations track server
Services --> Router Advertisement (both LANs): Assisted (or Managed, tried both)That's the general idea. Here was the basic timeline of changes, and when things went wrong:
2019: Installed the Protecli box with pfSense, ran one WAN (Cox) without issue until 2025. Never paid any attention to IPv6 config.
2025 - March-ish: got AT&T fiber, kept COX, configured Multi-WAN (no failover, no load-balancing), IPv4 worked fine, paid no attention to configuring IPv6. pfSense configuration changes do as expected, changes write config and apply immediately.
2025 - July-ish: configured IPv6 for both WANs / LANs, able to resolve IPv6 addresses and route IPv6 fine to Internet from LAN clients across both WANs / ISPs.
2025 - Sept / Oct - ish -- upgraded pfSense from 2.7.x to 2.8.0. Around the same time, discovered a problem with a commercial authenticator which appeared related to IPv6 resolution and routing.
2025 - last week of Oct / Nov - upgraded pfSense from 2.8.0 to 2.8.1. Discovered while IPv6 still working on AT&T WAN, not working anymore on Cox WAN. Started trying to debug it, discovered my IPv6 pfSense configuration changes were never getting reflected to config.xml or dhcp6c.conf file. What I saw was a dhcp6c.conf file with the AT&T WAN interface config still there, but the Cox WAN interface config not writing at all. Tried all manner of changes back / forth, saving / applying, restarting services, etc. to try to get that config to write. Here's an example of that state in the dhcp6c.conf:interface em0 { send ia-na 0; # request stateful address send ia-pd 0; # request prefix delegation request domain-name-servers; request domain-name; script "/var/etc/dhcp6c_wan_script.sh"; # we'd like some nameservers please }; id-assoc na 0 { }; id-assoc pd 0 { prefix ::/64 infinity; prefix-interface em1 { sla-id 0; sla-len 0; }; interface em3 { script "/var/etc/dhcp6c_opt2_dhcp6withoutra_script.sh"; };No matter what I tried, I couldn't get any prefix delegation settings to apply to em3. So I figured that somehow pfSense had gotten into a confused state, and it was preventing configuration from properly persisting. So I reset pfSense to factory settings, setting it up again as multi-WAN. But this time around, this problem manifested for both WANs, and the prefix delegation settings for both wouldn't persist. So now I had no working IPv6 for either AT&T or Cox. So I pulled the multi-WAN config out entirely, and configured for one single WAN, disconnected Cox entirely. Still I could not get IPv6 working on even a single WAN-LAN, in the exact same way it worked prior. The dhcp6c.conf remained as this:
interface em0 {
script "/var/etc/dhcp6c_wan_script.sh";
};So at this point -- I'm starting to think the problem is definitely with pfSense. So to test this, I did two different scenarios:
- I plugged my laptop directly into each AT&T and Cox modem. IPv6 worked totally fine.
- Since in my pfSense setup, I had a WiFi router on each LAN network plugged directly into each PfSense LAN port (tried with both router mode and AP mode) I bypassed pfSense completely, and plugged those WiFi routers directly into the AT&T and Cox modems. Each handled IPv6 fine, and resolved and routed IPv6 traffic from LAN clients just fine.
Barring something I've completely missed or misunderstood (entirely possible), there is no doubt -- the issue is pfSense. Also, it doesn't seem the issue is what IPv6 config settings are made, because it doesn't really matter what those settings are, they don't make it to the config files as I understand where those changes are supposed to be written and applied. As I understand it, none of my config settings are getting written, no matter what they are.
That is why I started my original post where I did, was to try to get some answers about what is supposed to happen when an IPv6 config change is saved and applied, and what possibilities could exist that would prevent config that appears and must be persisted somewhere b/c it displays in the UI console, from being used in the started services. I'm not claiming there's a big bug in pfSense v2.8.x, but there is a direct correlation between the time when I upgraded and encountering this issue. It doesn't mean that 2.8.x introduced it if there is a bug, it could have been a problem before. It also could be related to changing ISC DHCP to Kea DHCP -- I figured keeping the deprecated service would be more prone to problems than the newer Kea DHCP.
Or, perhaps there's some condition elsewhere in settings that I'm unaware of that does the magic, and I'm just ignorant. FYI -- I hope this is the solution, b/c it makes for a quick and easy fix. I'm not sure what more to try at this point, save another reset to factory settings, without setting up multi-WAN. If I had to take a stab in the dark, my long-shot bet would be either that there's something in multi-WAN setup that doesn't "undo" as it should, or that there's some problem with using Kea DHCP that pfSense doesn't handle properly. Maybe a factory reset while never configuring multi-WAN and switching back to ISC DHCP might be an idea.
Whatever the case, I greatly appreciate any responses or ideas or info from those in the know about how this works under the hood to help me get to resolution. I'd like to buy new and faster hardware, but this isn't a hardware issue (AFAIK) this is a software issue, and if this isn't something that can't be solved, I'm going to have to rethink my network strategy.
Thanks again for your help,
B -
I've figured the problem out -- TLDR: the combination of Kea DHCP and 2.8.x is broken. I took a new line of questioning with an LLM, and it stated outright this is a known problem with the changes in the 2.8.x configuration system and support for Kea DHCP. I reset my pfSense to factory settings and kept the deprecated ISC DHCP (did not use Kea) and IPv6 worked right out of the box -- config files showed proper IPv6 configuration. If anyone is interested in my LLM dialog, here it is (I edited out a bunch of troubleshooting steps, just kept the explanation):
MY PROMPT --------------------
Question — I’ve been pondering the so far unexplained reason why IPv6 configurations in pfSense don’t seem to be getting saved and written to configuration files. There are two primary changes that were made around the time this problem started. The first is that I upgraded pfSense from 2.7.x to 2.8.0 and then 2.8.1. The second change was changing the from ISC DHCP to Kea DHCP. Could either of these be the culprit?LLM ANSWER --------------------
That’s an excellent and very perceptive question — and yes, one of those two changes very likely explains why your IPv6 configuration state isn’t persisting or producing matching config files under /var/etc.Let’s look closely at both factors: the pfSense 2.8.x change and the Kea migration, and how they specifically impact the DHCPv6 and RA subsystems.
⸻
🧩 1️⃣ The pfSense 2.8.x Upgrade (Underlying OS + Config Daemon Changes)
Between 2.7.x → 2.8.x, pfSense made major backend changes:
• Base OS upgraded from FreeBSD 14.0-CURRENT → 14.1-STABLE.
• The config subsystem (configctl) was rewritten in Python for CE 2.8.x to match pfSense Plus.
• DHCPv6 handling logic was refactored to prepare for Kea integration.Known symptom
In 2.8.x builds, if:
• The configctl binary is missing or broken (configctl: command not found — which you’ve seen),
• or the service mapping files under /usr/local/etc/configd/actions.d/ are missing/corrupted,Then:
• The GUI “Apply” button appears to save,
• But the backend service commands never execute,
• So files like /var/etc/dhcp6c.conf, /var/etc/radvd.conf, /var/etc/kea/*.conf, etc., never get regenerated.
This matches exactly what we’re seeing — GUI changes not reflected in /var/etc.So the 2.8.x upgrade may have left configctl or its hooks nonfunctional.
⸻
🧩 2️⃣ The Switch from ISC DHCP → Kea DHCP
The second factor is definitely involved.
Here’s what happens when you switch pfSense’s DHCP engine from ISC DHCPd/dhcp6c to Kea:
Component Pre-Kea (2.7.x) Post-Kea (2.8.x)
DHCPv4 server /usr/local/sbin/dhcpd /usr/local/sbin/kea-dhcp4
DHCPv6 server /usr/local/sbin/dhcp6s /usr/local/sbin/kea-dhcp6
DHCPv6 client /usr/local/sbin/dhcp6c still ISC (for now)
Config generator /etc/rc.newwanipv6, /var/etc/dhcp6c.conf partially migrated to /var/etc/kea/kea-dhcp6.confpfSense CE 2.8.1 is in a hybrid state:
• DHCPv4 is fully Kea-managed.
• DHCPv6 client and relay behavior are still ISC-based.
• DHCPv6 server and RA integration are partially migrated to Kea.Unfortunately, this causes the exact problem you’re describing:
• The WebUI toggles still refer to dhcp6c and radvd logic.
• But when Kea is enabled, those generators are skipped, because pfSense thinks “Kea owns DHCP6 now.”
• The result: empty /var/etc/dhcp6c.conf and no running radvd process — even though the XML config looks fine....
This is now a known issue for some 2.8.1 users when Kea is active:
IPv6 configuration does not persist or generate runtime configs when Kea is enabled.So yes — your suspicion is right on the money:
Kea is the primary cause, and 2.8.x’s new config backend amplifies the issue by not always writing configs when Kea is active.⸻
-
@brado7274 happy it works for you. If your statement were true for pfSense 2.8.1 a lot more people would complain.
It does sounds very strange, you may trust the LLM a bit too much in my opinion in that case. They are known to give a lot of untrue information. It's certainly a good idea to cross check the information you get.
If the FreeBSD man pages are anything to go by neither
dhcp6snordhcp6care ISC software but from WIDE/KAME.The DHCP6 server is KEA (and KEA is also from the same company, ISC that created ISC DHCP) or ISC DHCP and the router advertisement daemon (RA) was never part of the ISC DHCP or KEA suite.
https://man.freebsd.org/cgi/man.cgi?query=dhcp6c
https://man.freebsd.org/cgi/man.cgi?query=dhcp6s
https://man.freebsd.org/cgi/man.cgi?query=radvdIf you want to help the pfSense devs you can backup your working config, switch to KEA and lets find the issue. By restoring your working config you can always get back.
Personally I'm not that good with reading long texts, listing with settings or screenshots are easier for me to process. But others will not have that limitation.
-
@patient0 said in IPv6 changes aren't written to config.xml or dhcp6c.conf:
I posted the resolution not so much for a debate, but to help anyone else experiencing something similar, and to let any devs that might be reading know and they could chase it down. But there are a few things perhaps I could give a little more color to:
If your statement were true for pfSense 2.8.1 a lot more people would complain.
I'm not sure that's necessarily the case. Switching from ISC to Kea alone might not cause an immediate problem, it might just lay a trip wire that isn't tripped until other IPv6 changes are made. I cannot say whether that's any IPv6 change or a specific one, but there's no doubt that there's a problem related to this. So just because folks upgraded to 2.8.x and are using Kea doesn't necessarily mean their system would immediately experience symptoms. They might not be making IPv6 changes immediately after. The system might use the same config files which were there prior, and so function would appear to be fine. But once the new config generation for IPv6 was tripped, perhaps that's what triggers the issue.
It does sounds very strange, you may trust the LLM a bit too much in my opinion in that case. They are known to give a lot of untrue information. It's certainly a good idea to cross check the information you get.
Bigger conversation, but AI is the most misapplied tech perhaps of our lifetimes. I don't trust any LLM -- but that said, it beats any search engine, and is great for grokking doc (which usually leaves much to be desired), APIs, libraries, etc. -- and narrowing the area to test and debug. Even when it is not completely right, perhaps b/c of version or feature variations, it can get you close, and in this case, its info squared exactly with the behavior.
I'm not the expert on the underlying pfSense code or the architecture under the hood, and whether the LLM explanation is 100% accurate, or if there are other nuances in play. Devs would be the right ones to speak to that -- but as there have been no other explanations provided, and this one squares perfectly with the behavior exhibited, until another explanation can explain it -- it stands.
If you want to help the pfSense devs you can backup your working config, switch to KEA and lets find the issue. By restoring your working config you can always get back.
That's basically what I did already -- I just didn't dig deeper to try to debug the issue at a code level. But it is certainly enough for those in that position run with it. There is absolutely a bug in pfSense, somewhere in 2.8.x apparently related to Kea DHCP and the generation of configuration. Using the UI admin console only should not be able to put pfSense in a state it cannot function properly or recover from.
I'm glad there was a way through it (factory reset, stick with ISC DHCP), and I hope it gets fixed. Without a workaround, pfSense would have been a no-op, I would have had to dump it immediately and switch to a different firewall, which I didn't want to do.
Thanks,
B -
Just as an FYI -- I went through this whole drill again, and reproduced the same behavior I've reported yet again. For any devs that might be reading, I may not have emphasized enough the aspect of multi-WAN in play, which appears to be the thing which throws it sideways.
As mentioned, I have two ISPs, AT&T Fiber, and Cox Cable Modem. Both work fine, both lines have been tested and are fine, getting expected bandwidth, and no noise on the line. Both support and route IPv6 just fine, when pfSense is removed from the equation. So the constituent parts of the equation are all proven to be working.
When resetting pfSense to factory settings, with only one WAN connection in play, IPv6 configured, resolved, and routed nearly by default. No problems at all. But as soon as you add the second WAN connection, and its associated LAN, that's when things don't work as advertised. No IPv6 config changes made on the second WAN / LAN take, and it appears this is true regardless of whether ISC DHCP or Kea DHCP is in play. Change IPv6 config on that second WAN / LAN, and those changes will never make it to the underlying OS config files. I looked at the config files manually -- they do not take, not when save and applying, nor after a restart of the box.
I'm not the expert on the internals under the hood, but hopefully this gets some devs in the vicinity of the issue. If the config generation functionality was indeed overhauled in 2.8.x as the LLM I consulted reported, it seems like whatever affect multi-WAN inflicts on that, it results in config for the second WAN doesn't take, and possibly with additional changes it ceases to write config for either WAN. But removing the second WAN / LAN connections and resetting cleans it up again.
I hope that helps. I've spent many days and hours testing this, and while there may be a way through, for all practical purposes, I consider pfSense no longer to have viable multi-WAN functionality as of 2.8.x (until a future fix materializes). I've had to run the second WAN/LAN around pfSense on different hardware.
Here's to hoping that both a definitive explanation of the cause and fix surfaces in the near future. I'd like to not have to punt pfSense entirely to support multi-WAN.
-
@brado7274 A separate unique WAN+LAN is probably pretty uncommon I’d think, compared to just multiple WANs and multiple internal networks. If I understood correctly.
If you can reproduce it you can file a report at Redmine.pfsense.org.
-
There's a related quirk there were depending on the config changes being done, you may need to re-save / apply the interface config for any WAN and LAN with related IPv6 settings. For example if LAN tracks WAN then changing the LAN config may also require re-saving WAN. That's the likely explanation for why you weren't seeing the prefix delegation config reflected in /var/etc/dhcp6c.conf.
That doesn't explain why you're now not seeing the second WAN's config at all, especially after a reboot. I've tested the setup on 25.07.1 which has a similar code base to 2.8.1 (i.e. any issues/fixes should affect both versions) and things behave as expected there.
-
@brado7274 said in IPv6 changes aren't written to config.xml or dhcp6c.conf:
Known symptom
In 2.8.x builds, if:
• The configctl binary is missing or broken (configctl: command not found — which you’ve seen),
• or the service mapping files under /usr/local/etc/configd/actions.d/ are missing/corrupted,Yeah, that is just plain wrong. Yet the LLM sounds very convincing, as it's designed to be.
But obviously that file should still be generated.
Just to be clear you initially said you tried testing with only one WAN and still didn't see the file correctly populated. But is that not in fact correct? You only see this with two WANs configured for IPv6?
