@marchand.guy you understand that an update would of cleared the cache - so for sure the numbers would be lower after this. Wait a few days to let your normal browsing habits stabilize.

@skybot said in pfSense CE 2.8.0 upgrade stalls after reboot and gets stuck in Stage 2: Unfortunately, switching from UEFI to BIOS is not an option in my environment. At this point I am stuck and don’t know how to proceed further. Has anyone found a workaround or solution for this issue on HPE ProLiant systems? Any advice or ideas would be greatly appreciated. How many different USB sticks, and which disk imager programs have you tried to create your bootable media with?

@bmeeks your work outclasses so many individuals of the next generation of developers. Your stuff is amazing. Cheers

I've solved it with a script and a cron-job in the mean time: #!/bin/sh Fetch public IP with debugging PUBLIC_IP=$(curl -4 ipinfo.io/ip 2>/dev/null) if [ -z "$PUBLIC_IP" ]; then logger -t ddns "Failed to get public IP from ipinfo.io" exit 1 fi logger -t ddns "Public IP: $PUBLIC_IP" No-IP update NOIP_USER="USERNAME" NOIP_PASS="PASSWORD" NOIP_HOST="SUBDOMAIN.ddns.net" NOIP_RESPONSE=$(curl -s "http://$NOIP_USER:$NOIP_PASS@dynupdate.no-ip.com/nic/update?hostname=$NOIP_HOST&myip=$PUBLIC_IP") logger -t ddns "No-IP ($NOIP_HOST): $NOIP_RESPONSE" But I still want to figure out the official fix of course!

@justme2 Get your SFTP browser, open /usr/local/www/services_dhcp_relay.php Or use the console or SSH, and edit /usr/local/www/services_dhcp_relay.php Locate : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface.'), 'danger', false); } Chance for : if ($dhcpd_enabled) { print_info_box(gettext('DHCP Relay cannot be enabled while DHCP Server is enabled on any interface. !! OVERRIDDEN !!'), 'danger', false); $dhcpd_enabled = false; } Note : the "!! OVERRIDEN !!" is my personal choice, and not needed. Save. Now, for example : I disabled the DHCP server (kea) for this interface : [image: 1757669144546-1208eea8-273b-4632-aa28-447a19ca7d92-image.png] Save and Apply. Back to DHCP relay, select IDRAC - add a DHCP Relay server : [image: 1757669183530-4a1df8ab-bc3b-41ce-9da3-edd2d04bfacc-image.png] and Save. Check : [25.07.1-RELEASE][root@pfSense.bhf.tld]/root: ps aux | grep 'dhc' root 26880 10.2 0.6 43768 23968 - S 11:18 0:00.10 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.conf root 27281 9.9 0.6 43728 23532 - S 11:18 0:00.09 /usr/local/sbin/kea-dhcp6 -c /usr/local/etc/kea/kea-dhcp6.conf root 24435 0.0 0.1 14404 2980 - Is 20Aug25 0:00.02 dhclient: system.syslog (dhclient) root 41257 0.0 0.1 14404 3100 - Is 20Aug25 0:00.05 dhclient: ix3 [priv] (dhclient) root 51257 0.0 0.1 14308 3460 - SCs 20Aug25 0:39.41 /usr/sbin/syslogd -O rfc5424 -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf -b 192.168.1.1 _dhcp 51487 0.0 0.1 14408 3268 - SCs 20Aug25 0:05.22 dhclient: ix3 (dhclient) root 52757 0.0 0.1 14128 2900 - Is 20Aug25 0:06.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid ix3 root 56422 0.0 0.1 16812 4776 - Is 11:10 0:00.00 /usr/local/sbin/dhcrelay -id igc2 -iu ix3 192.168.10.1 The kea DHCPv4 is still running. If all goes well, it doesn't touch/use the igc2 - my "IDRAC" - interface. As you can see, dhcrelay is running also - using 'igc2' - my IDRAC interface. You'll notice that on the DHCPv4 (kea, as that's what I'm using) there are also red messages showing. [image: 1757668428078-c8d71175-a0b8-4fd6-b081-18138c5027b5-image.png] Also for the LAN, and other interfaces. I guess you know now how to make these GUI pages more "smart", and don't show messages if they are not needed. On the DHCP Relay GUI page you could even modify the list with shown network, by excluding the networks that have the DHCPv4 active on them. In my case : this list should only shown "IDRAC" instead of : [image: 1757669589057-fe81bc41-f103-4a54-be83-890688b52a39-image.png] Btw : I did not test this dhcrelay service. I don't have a network where this is needed / don't know how to use it. Also : I presume you cant' save DHCOPv4 ((kea) settings and network pages anymore, as on this pages the test 'is dhcp relay' running also exist (Generaol settings page : just the test, on the interface(s) page - the same PHP file is used for all interfaces the test also exist, and name some love). I'll leave it up to you a make something nice, safe and fool proof out of it. Like : If you select an interface, like my IDRAC, that has a dhcp relay activated on it, show the red message and don't allow the user to Enable it with an active DHCP server. This is now already the case. Make the code a bit smarter by testing the (this) interface is used by dhcp relay, and only allow the DHCP server (kea) to be activated on that interface if it is not used by dhcp relay. See /usr/local/www/services_dhcp.php- here : [image: 1757669965048-4812bf5d-0bca-4afb-a4f0-8e0173cd984f-image.png] how to make these decisions.

@stephenw10 I just uploaded the pcap file. Hopefully there's something useful in it.

@JeGr In der Tat, nicht genau genug gelesen.

@chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: I have fully working inbound ICMP which is fine Inbound on .. LAN or WAN ? The default behavior of LAN : TCP, UDP, ICMP, and dozens of other protocols are allowed. WAN : nothing, meaning zero, which wasn't initiated from pfSense itself (or some LAN device), can enter. @chrcoluk said in Where are the inbound rules for routeable IPv6 on LAN interfaces? Solved: it is the WAN rule, logging didnt show it as its using an established state. What WAN rule ? If traffic comes in on WAN and it is established traffic, then initially, it was granted by an existing WAN firewall rule, one you place there yourself. Subsequent traffic, from the same traffic stream, will be granted right away. If you want WAN to reply on ICMPv4 from some device on the Internet, you need to create firewall rule on WAN that grants access from this device (this device, using its source IP, or "any" for everybody) selecting some or all ICMPv4 types of traffic. By default, pfSense will not reply on ICMP request coming into (= inbound into WAN) the WAN.

resolved! Issue was the following I corrected a few things on your config: Your Outbound NAT configuration was malformed. I corrected it to utilize Hybrid mode and configured a single Outbound NAT for your Wireguard connection, which should be much cleaner. I updated your routing table to be Automatic and switched to Policy-based routing within the firewall rules under Firewall --> Rules --> LAN I updated the name of the interface for the Wireguard tunnel to be called TORGUARD and set the MSS clamping to 1350. This can probably be bumped back up to 1400, but I wanted to make sure the clamping was small enough to avoid fragmentation. I cleaned up some redundant firewall rules and a few other "odds and ends".

Yup the check that fails is during boot. The alert should be there however long you wait to login. But, yes, it's just ugly. It shouldn't actually be a problem.

What exactly are you counting as a leak test failure? If you're forwarding requests to Cloudflare then DNS tests will always show Cloudflare. It just might be local servers if the query isn't over the VPN.

@wesley33taylor okay, now I have to ask, just due to being especially dense today, what and how did you do that? what do others need to change, so that there is written history for anyone else that might end up finding this thread and wanting to do the same, the usefulness of archival purposes and the desire to confirm I've done the same drive me to ask this. please advise.

I've done some testing yesterday. Testing was largely about reaching shared folder on LAN client from WiFi client. I was testing host name vs IP. I have to make sure that DNS queries are not blocked. In my configuration WiFi interface in general can only reach WAN, not LAN and I have many disabled rules that I activate (one at a time) when I need to reach a LAN client. I noticed that turning off Windows firewall on the LAN client helped in allowing WiFi client to reach it but I think this was in the case of using IP. Host name still did not work. Windows firewall was never an issue but that is when I only had Win7 machines at home. Now that I have added Win11 to the mix they might not be playing nice with each other with default settings. Adding secondary DNS (of the other interface) under each interface's DHCP Server may also be needed. I will also look at the DNS Resolver and Forwader to see if I need to change anything there. I will be testing DNS (rules/settings) and Windows firewall settings while running packet capture. This will take a few days but I know what to focus on and will report back with my findings.

@gambit100 That file is really not usefull, as it doesn't show the contents. I ran Wireshark, filtering on ICMP6. Here's a list of the packets received, with the RA in the top row: [image: 1757623267241-17d2a377-a2cc-4179-aa71-f0ba19566d2d-image.png] Here is the contents of that frame, showing the relevant info. Several items can be expanded further: [image: 1757623471656-826054d0-050a-4992-890f-b88e7057c4e5-image.png] This is the sort of thing you need to understand network problems. You can use Packet Capture, in pfSense, but I find Wireshark is much better. Even if you capture with Packet Capture, you're still better off examining the capture with Wireshark. Now, if you look at the options, you'll see things like assigned addresses and DNS.

Hmm, well it should start at boot. If it fails to start I'd expect some error to be logged.