Suspected bug: DHCPv6 Fails on igc Driver Interfaces After Upgrade to pfSense 25.11.1 / FreeBSD 16 — IPv6 Multicast UDP sendto Returns EPERM
-
Looking for confirmation before posting the below to Redmine.
Summary
Following an upgrade from pfSense 25.07.1 (FreeBSD 15) to pfSense 25.11.1 (FreeBSD 16-CURRENT), DHCPv6 client (
dhcp6c) fails to obtain IPv6 addresses on WAN interfaces using the Intel I225-V (igc) NIC driver. Interfaces using the Intel X553 (ix) driver on the same system obtain DHCPv6 assignments without issue using the identical dhcp6c binary, configuration file, and socket operations. IPv6 via DHCPv6 was fully functional on all interfaces under pfSense 25.07.1/FreeBSD 15.System call tracing confirms that IPv6 multicast UDP
sendtotoff02::1:2(All_DHCP_Relay_Agents_and_Servers, port 547) returnsEPERM (Permission denied)exclusively onigcdriver interfaces. Identicalsendtocalls onixdriver interfaces on the same system succeed. This is a regression in theigcdriver's IPv6 multicast send path between FreeBSD 15 and FreeBSD 16.
Environment
Field Value pfSense version 25.11.1-RELEASE FreeBSD version 16.0-CURRENT Previous working version pfSense 25.07.1 / FreeBSD 15 dhcp6c package dhcp6-20080615.2_4 Affected NIC driver igc (Intel I225-V, PCI device 0x8086:0x15f3) Working NIC driver ix (Intel X553, PCI device 0x8086:0x15c4 / 0x15e5) Hardware Official Netgate 6100 appliance Issue onset Immediately following upgrade to 25.11.1 ISP on affected interface Comcast/DOCSIS cable (igc3); 3 physical WAN connections, 2 of the 3 (ix2 and ix3 obtain an an assignment from their ISPs via dhcp6 without issue
Hardware Inventory
Failing interfaces — igc driver (Intel I225-V):
igc0@pci0:4:0:0 vendor=0x8086 device=0x15f3 Intel Ethernet Controller I225-V igc1@pci0:5:0:0 vendor=0x8086 device=0x15f3 Intel Ethernet Controller I225-V igc2@pci0:6:0:0 vendor=0x8086 device=0x15f3 Intel Ethernet Controller I225-V igc3@pci0:7:0:0 vendor=0x8086 device=0x15f3 Intel Ethernet Controller I225-VWorking interfaces — ix driver (Intel X553):
ix0@pci0:3:0:0 vendor=0x8086 device=0x15c4 Intel Ethernet Connection X553 10GbE SFP+ ix1@pci0:3:0:1 vendor=0x8086 device=0x15c4 Intel Ethernet Connection X553 10GbE SFP+ ix2@pci0:2:0:0 vendor=0x8086 device=0x15e5 Intel Ethernet Connection X553 1GbE ix3@pci0:2:0:1 vendor=0x8086 device=0x15e5 Intel Ethernet Connection X553 1GbE
Symptoms
- COMCAST_DHCP6 gateway shows Pending indefinitely in Status → Gateways
ifconfig igc3 inet6shows only link-localfe80::address — no global unicast address assigned- DHCPv6 was fully functional on the same hardware and ISP under pfSense 25.07.1/FreeBSD 15
- Other WAN interfaces on
ixdriver obtain DHCPv6 assignments normally
Troubleshooting Steps and Evidence
Step 1: Confirmed Link-Local Address and ISP DHCPv6 Support
Link-local address confirmed present on the affected interface — DHCPv6 prerequisite satisfied:
$ ifconfig igc3 inet6 igc3: inet6 fe80::xxxx:xxxx:xxxx:xxxx%igc3 prefixlen 64 scopeid 0x4 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>Router Solicitation confirmed ISP is sending RAs with M and O flags set, requiring stateful DHCPv6. SLAAC is not available (all RA prefix info options carry
Flags [none]):$ rtsol -D igc3 rtsol: received RA from fe80::xxxx:xxxx:xxxx:xxxx on igc3 rtsol: ManagedConfigFlag on igc3 is turned on rtsol: OtherConfigFlag on igc3 is turned onRA prefix advertisements from ISP confirmed flowing correctly:
$ tcpdump -r /tmp/dhcp6_comcast.pcap -n -v xx:xx:xx IP6 fe80::xxxx:xxxx:xxxx:xxxx > ff02::1: ICMP6 router advertisement prefix info: 2001:xxx:xxxx::/64, Flags [none], valid 604800s prefix info: 2001:xxx:xxxx::/64, Flags [none], valid 604800s prefix info: 2001:xxx:xxxx::/64, Flags [none], valid 604800s prefix info: 2001:xxx:xxxx::/64, Flags [none], valid 604800sStep 2: Confirmed Firewall Rules Are Correct
All required DHCPv6 pass rules are present and correctly configured for the affected interface:
$ pfctl -s rules | grep igc3 | grep -i "dhcp\|546\|547" pass in quick on igc3 inet6 proto udp from fe80::/10 port = dhcpv6-client \ to fe80::/10 port = dhcpv6-client keep state (if-bound) \ label "descr=allow dhcpv6 client in COMCAST" pass in quick on igc3 proto udp from any port = dhcpv6-server \ to any port = dhcpv6-client keep state (if-bound) \ label "descr=allow dhcpv6 client in COMCAST" pass out quick on igc3 proto udp from any port = dhcpv6-client \ to any port = dhcpv6-server keep state (if-bound) \ label "descr=allow dhcpv6 client out COMCAST"Step 3: Confirmed dhcp6c Builds Solicit Correctly But Fails to Transmit
Running dhcp6c in foreground debug mode shows the Solicit packet is correctly constructed but every transmission fails:
$ /usr/local/sbin/dhcp6c -d -D -f -c /var/etc/dhcp6c.conf igc3 xx:xx:xx: reset a timer on igc3, state=INIT, timeo=0, retrans=891 xx:xx:xx: Sending Solicit xx:xx:xx: a new XID (xxxxxx) is generated xx:xx:xx: set client ID (len 14) xx:xx:xx: set identity association xx:xx:xx: set elapsed time (len 2) xx:xx:xx: set option request (len 4) xx:xx:xx: set IA_PD prefix xx:xx:xx: set IA_PD xx:xx:xx: transmit failed: Permission denied xx:xx:xx: reset a timer on igc3, state=SOLICIT, timeo=0, retrans=1091 xx:xx:xx: Sending Solicit xx:xx:xx: transmit failed: Permission deniedThis repeats indefinitely with exponential backoff. No DHCPv6 Advertise is ever received.
Step 4: Confirmed Packet Never Reaches pf — Block Is at Kernel Level
An explicit logging pass rule was added to the pf ruleset permitting DHCPv6 multicast output on the affected interface:
$ printf 'pass out log quick on igc3 inet6 proto udp from any to ff02::1:2 port 547 no state\n' \ > /tmp/dhcp6_fix.anchor $ pfctl -a "dhcp6_igc3" -f /tmp/dhcp6_fix.anchor $ pfctl -a "dhcp6_igc3" -s rules pass out log quick on igc3 inet6 proto udp from any to ff02::1:2 port = dhcpv6-server no stateMonitoring pflog while dhcp6c was actively attempting to send Solicits showed zero DHCPv6 packets from igc3 in the pf log. Traffic from other interfaces appeared normally. The packet never reaches pf for evaluation — the kernel rejects it before the firewall layer.
Step 5: Smoking Gun — System Call Trace Comparing igc vs ix Interfaces
Running all three WAN interfaces simultaneously under truss reveals the definitive cause:
$ truss /usr/local/sbin/dhcp6c -d -f -c /var/etc/dhcp6c.conf igc3 ix2 ix3 \ |& grep -E "setsockopt|sendto\(3" setsockopt(3,SOL_SOCKET,SO_REUSEPORT,...) = 0 setsockopt(3,IPPROTO_IPV6,IPV6_RECVPKTINFO,...) = 0 setsockopt(3,IPPROTO_IPV6,IPV6_MULTICAST_LOOP,...) = 0 setsockopt(3,IPPROTO_IPV6,IPV6_V6ONLY,...) = 0 sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) ERR#13 'Permission denied' ← igc3 FAILS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 68 ← ix2 SUCCEEDS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 68 ← ix2 SUCCEEDS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 126 ← ix3 SUCCEEDS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) ERR#13 'Permission denied' ← igc3 FAILS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 95 ← ix3 SUCCEEDS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) ERR#13 'Permission denied' ← igc3 FAILS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 52 ← ix2 SUCCEEDS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) ERR#13 'Permission denied' ← igc3 FAILS sendto(3,...,{ AF_INET6 [ff02::1:2]:547 }) = 52 ← ix2 SUCCEEDSKey observations:
- All interfaces share a single socket (FD 3) with identical socket options
- Identical
sendtodestinationff02::1:2port 547 igc3(Intel I225-V,igcdriver) returnsERR#13 EPERMon every attemptix2andix3(Intel X553,ixdriver) succeed on every attempt- The failure is 100% correlated with the
igcdriver — not dhcp6c configuration, not firewall rules, not ISP behavior
Driver Capability Comparison
$ ifconfig -v igc3 | grep options options=4e020bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU, VLAN_HWCSUM,WOL_MAGIC,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG> $ ifconfig -v ix3 | grep options options=4e138bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU, VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER, RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>Note
igc3is missingWOL_MCASTandVLAN_HWFILTERcompared toix3, which may be symptomatic of incomplete multicast support in theigcdriver under FreeBSD 16, though the relationship to thesendtofailure requires further investigation by the driver maintainers.
Root Cause Assessment
IPv6 multicast UDP
sendtotoff02::1:2:547returnsEPERMon interfaces driven by theigcdriver (Intel I225-V, PCI 0x8086:0x15f3) under FreeBSD 16-CURRENT. Identical operations succeed onixdriver interfaces (Intel X553, PCI 0x8086:0x15c4 / 0x15e5) on the same system. This is a regression introduced between FreeBSD 15 (pfSense 25.07.1) and FreeBSD 16 (pfSense 25.11.1), likely in theigcdriver's IPv6 multicast transmit path or in a FreeBSD 16 kernel change affecting howigchandles multicast socket sends.
Impact Summary
Interface Driver PCI Device DHCPv6 Result sendto Result igc3 igc 0x8086:0x15f3 Fails ERR#13 EPERM ix2 ix 0x8086:0x15e5 Succeeds 68 bytes ix3 ix 0x8086:0x15e5 Succeeds 95 bytes
Expected Behavior
DHCPv6 Solicit packets should be successfully transmitted on
igcdriver interfaces, as they were under pfSense 25.07.1/FreeBSD 15, allowing IPv6 address and prefix delegation assignment from the ISP.Actual Behavior
Every DHCPv6 Solicit transmission on
igcdriver interfaces returnsEPERMat the kernel level. No IPv6 global unicast address is obtained. The gateway remains in Pending state indefinitely.Workaround
None currently identified without kernel or driver-level intervention.
Suggested Investigation Path
- Review changes to the
igcdriver's multicast transmit path between FreeBSD 15 and FreeBSD 16 - Review any FreeBSD 16 kernel changes affecting
IPPROTO_IPV6socket multicast send permissions on a per-driver basis - Compare
igcandixdriver handling of outbound IPv6 multicast UDP under FreeBSD 16
-
Observe same on pfSense 2.9.0 CE
xx:xx:xx: Sending Solicit xx:xx:xx: transmit failed: Permission deniedem0@pci0:0:31:6: class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x156f subvendor=0x8086 subdevice=0x0000 vendor = 'Intel Corporation' device = 'Ethernet Connection I219-LM' class = network subclass = ethernet -
I was able to fix this with a custom NAT rule. This was not necessary in 2.8.1 so seems like the autogenerated NAT rule logic changed between this and 2.9.
Do not NAT Interface: WAN Address Family: IPv6 Protocol: UDP Source: any, Port: 546 Destination: any, Port: 547 Description: "Exclude DHCPv6 client from NAT"On my system at least, the automatic NAT rules included this:
nat on em0 inet6 proto udp all -> (em0) round-robin static-portNAT rules get caught before filter rules, so the wildcard matches and then I think it fails to translate the source address since it appears to be coming from
::so then you get:
pf_map_addr_sn: pf_map_addr has failedlogged to dmesg
pf: NAT proxy port allocation (0-0) failedlogged to dmesg
pf returnsPF_DROP→ pfil returnsPFIL_DROPPED→ EACCES returned to userspace -
@bdwyertech I am also affected by this issue, and it does seem like it might be the autogenerated NAT rule logic as it worked in previous version.
Is there any chance you could share a screenshot of your rule for outbound NAT, as well as the custom NAT rule. I tried the custom NAT rule and it seems like I have to mess with outbound NAT as well, but then it ends up breaking ip4 NAT so I am sure I am doing something wrong.
Many thanks!
-
@TravisH said in Suspected bug: DHCPv6 Fails on igc Driver Interfaces After Upgrade to pfSense 25.11.1 / FreeBSD 16 — IPv6 Multicast UDP sendto Returns EPERM:
@bdwyertech I am also affected by this issue, and it does seem like it might be the autogenerated NAT rule logic as it worked in previous version.
Is there any chance you could share a screenshot of your rule for outbound NAT, as well as the custom NAT rule. I tried the custom NAT rule and it seems like I have to mess with outbound NAT as well, but then it ends up breaking ip4 NAT so I am sure I am doing something wrong.
Many thanks!
please!
-
@bdwyertech said in Suspected bug: DHCPv6 Fails on igc Driver Interfaces After Upgrade to pfSense 25.11.1 / FreeBSD 16 — IPv6 Multicast UDP sendto Returns EPERM:
I was able to fix this with a custom NAT rule. This was not necessary in 2.8.1 so seems like the autogenerated NAT rule logic changed between this and 2.9.
Do not NAT Interface: WAN Address Family: IPv6 Protocol: UDP Source: any, Port: 546 Destination: any, Port: 547 Description: "Exclude DHCPv6 client from NAT"On my system at least, the automatic NAT rules included this:
nat on em0 inet6 proto udp all -> (em0) round-robin static-portNAT rules get caught before filter rules, so the wildcard matches and then I think it fails to translate the source address since it appears to be coming from
::so then you get:
pf_map_addr_sn: pf_map_addr has failedlogged to dmesg
pf: NAT proxy port allocation (0-0) failedlogged to dmesg
pf returnsPF_DROP→ pfil returnsPFIL_DROPPED→ EACCES returned to userspaceThis solved my issue. Thanks!
-
@bdwyertech that worked for me as well. Many thanks!
Privacy Policy · Cookie Policy