pfSense » pfSense Plus

1. 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 `sendto` to `ff02::1:2` (All_DHCP_Relay_Agents_and_Servers, port 547) returns `EPERM (Permission denied)` exclusively on `igc` driver interfaces. Identical `sendto` calls on `ix` driver interfaces on the same system succeed. This is a regression in the `igc` driver's IPv6 multicast send path between FreeBSD 15 and FreeBSD 16.

---

1. 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

---

1. 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-V
```

Working 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
```

---

1. Symptoms

- COMCAST_DHCP6 gateway shows Pending indefinitely in Status → Gateways
- `ifconfig igc3 inet6` shows only link-local `fe80::` 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 `ix` driver obtain DHCPv6 assignments normally

---

1. Troubleshooting Steps and Evidence

1. 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 on
```

RA 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 604800s
```

1. Step 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"
```

1. 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 denied
```

This repeats indefinitely with exponential backoff. No DHCPv6 Advertise is ever received.

1. 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 state
```

Monitoring 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.

1. 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 SUCCEEDS
```

Key observations:
- All interfaces share a single socket (FD 3) with identical socket options
- Identical `sendto` destination `ff02::1:2` port 547
- `igc3` (Intel I225-V, `igc` driver) returns `ERR#13 EPERM` on every attempt
- `ix2` and `ix3` (Intel X553, `ix` driver) succeed on every attempt
- The failure is 100% correlated with the `igc` driver — not dhcp6c configuration, not firewall rules, not ISP behavior

---

1. 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 `igc3` is missing `WOL_MCAST` and `VLAN_HWFILTER` compared to `ix3`, which may be symptomatic of incomplete multicast support in the `igc` driver under FreeBSD 16, though the relationship to the `sendto` failure requires further investigation by the driver maintainers.

---

1. Root Cause Assessment

IPv6 multicast UDP `sendto` to `ff02::1:2:547` returns `EPERM` on interfaces driven by the `igc` driver (Intel I225-V, PCI 0x8086:0x15f3) under FreeBSD 16-CURRENT. Identical operations succeed on `ix` driver 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 the `igc` driver's IPv6 multicast transmit path or in a FreeBSD 16 kernel change affecting how `igc` handles multicast socket sends.

---

1. 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

---

1. Expected Behavior

DHCPv6 Solicit packets should be successfully transmitted on `igc` driver interfaces, as they were under pfSense 25.07.1/FreeBSD 15, allowing IPv6 address and prefix delegation assignment from the ISP.

1. Actual Behavior

Every DHCPv6 Solicit transmission on `igc` driver interfaces returns `EPERM` at the kernel level. No IPv6 global unicast address is obtained. The gateway remains in Pending state indefinitely.

1. Workaround

None currently identified without kernel or driver-level intervention.

1. Suggested Investigation Path

1. Review changes to the `igc` driver's multicast transmit path between FreeBSD 15 and FreeBSD 16
2. Review any FreeBSD 16 kernel changes affecting `IPPROTO_IPV6` socket multicast send permissions on a per-driver basis
3. Compare `igc` and `ix` driver handling of outbound IPv6 multicast UDP under FreeBSD 16