Due to personal circumstances, I'm on a network that I don't manage myself... it blocks things like VPNs if they'd be actually configured in the built-in VPN settings at the OS/router level. OpenVPN Connect on Windows, however, works perfectly fine! (much like those DNS relay applications for when the normal use of custom DNS is blocked, firewall at this place thinks that my PC-shaped router is constantly talking to a bank or something and just lets it happen when using OpenVPN Connect)

This is what the physical topology looks like currently:

WISP router connected to their network through WiFi on its WAN side --Ethernet from LAN port--> Old PC with Windows that connects to my VPN (OpenVPN Access Server on a DigitalOcean Droplet), with a VirtualBox VM sporting pfSense 2.8.1: WAN = VirtualBox NAT that I created, LAN = direct to USB-Ethernet adapter ----> 5-port unmanaged switch for wired clients and an ASUS router set to AP mode ----> clients

I'm trying to figure out the route that goes from the VPN's subnet to the VirtualBox NAT, so I can get port forwarding working.

Subnets:
WISP router: 192.168.72.0/24
VPN: 192.168.192.0/24
VirtualBox NAT: 192.168.85.0/24
pfSense VM's LAN: 192.168.44.0/24

I just took a look at the "route print" of the bare machine, no mention of the VirtualBox NAT subnet at all... would it be wise to add a route from the VPN one to that VirtualBox NAT one?

It does work when I run a Minecraft server for example, (I always set one up locally, just to test the ability of port forwarding through VPNs/multi-subnet setups) on the bare metal, but not when running it on one of the clients in the pfSense subnet.

Thanks in advance!

\\ Wesley, from the Netherlands

I have a backup 4G WAN connection which gets a new ip every 24 hours.
But I've noticed that in the FRR routing table all the old entries are still present.
I see 322 entries like this (1 for each 24 hours). Every time a different subnet:

C>* 178.225.15.0/24 [0/1] is directly connected, ix3, 00:03:20

They seem to remain there until I reboot the device.

Is there any way these can get cleanup automatically after the interface gets a new ip via DHCP ?

We opened a support case last year, #34394088536, and configured rules with specific Gateway Groups as a solution, after a second tech pointed out this bug.

This morning, our client's 6100 did not failover to Starlink. I lost the logs when a tech rebooted the firewall so I don't have specifics from today. The client is not at all excited about the situation, especially when I opened a support case last year and told the client it was resolved.

It appears that this bug, or Starlink problem that all firewall makers need to work around, has not received any attention other than the initial acknowledgement.

Starlink is selling a lot of kit and is a relatively inexpensive option for a rarely used 2ndary circuit vs a 2nd fiber circuit. It would be helpful if this very long known issue received some attention.

It appears that other firewall vendors have dealt with the same problem related to DHCP option 121 on the WAN. It is unclear why pfSense has not solved this, particularly when the original submission provides at least one option for resolution.

Starlink: DHCP option 121? No more need to add a static route to 192.168.100.1?
Unifi: Gateway target 0.0.0.0 and not routing packets
Meraki and Starlink Deployment Guide (See Additional Considerations)

I would much prefer a vetted and supported resolution from Netgate vs DIY code in production firewalls.

Thank you.

I need to get a route from my proxmox-server via pfsense to a nas in subnet behind fritzbox Wireguard VPN.

Proxmox bridge 192.168,175,69/24 to pfsense 192.168.175.68/24
IP route is added direction nas (192.168.1,50/24) via pfsense (192.168.175.68)
This way between proxmox and pfsense is pingable in both directions.

Now I need to go on with my packets from pfsense through a site-to-side with wireguard.
The wireguard interface has no gateway. it is routet by static routes.
Tunnel is working in both directions and to subnet behind fritzbox.

Means I dont get the routing inbound OPT1 (Proxmox<->Pfsense) through the wireguard tunnel to nas with ip 192.168.1.50/24.
The ping from interface OPT1 to final ip behind wiregard ist 100% loss.

I really tried everything, but I am stuck after 4 hrs of testing...

Thanks in advance for your help.

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.

Environment

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

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

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

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"

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.

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.

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

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.

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.

Impact Summary

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.

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.

Workaround

None currently identified without kernel or driver-level intervention.

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

Now traffic, that orginates from this interface, that is suppose to use OSPF to a remote location does not route.

How can I put the OSPF routes first and keep the gateway group with WAN2 as primary?