@Gertjan said in IPv6 Prefix Delegation Host-Address: Ask them Here you go (about 4 years ago): https://redmine.pfsense.org/issues/12600 https://redmine.pfsense.org/issues/12602 Btw. I add ASN for the ISPs in question to the TS-forward via pfBlocker. This works good for IPv6, but still, it would be nice to have even more control...

I agree handle one issue at a time, not working on any port forwarding until workstations can get to internet Keith

You guys are arguing over semantics.. vlan/network its the same freaking thing.. If someone says they are on a specific vlan, that is a L2 network with 1 IP network on it (L3).. Please explain this setup of yours @tinfoilmatt where over your "vlans" you see other computers. Since clearly me and James have no clue to what your talking about. Tell use how @louis2 is suppose to find his other computers sharing stuff via smb " However only shares in the same VLAN are visible." So clearly his is using either mdns or Web Services Dynamic Discovery (WS-Discovery) to find these servers. Or maybe LLTD.. or maybe the simple netbios-ns or NBNS (port 137 you mention).. Which is going to be a broadcast to all FFs, most likely at layer 3 a directed broadcast say 192.168.1.255 if he is using 192.168.1.0/24 as one of his networks/vlans. Or in the case of say mdns or ws-discovery or lltd a multicast. Or some other discovery to find the computer on another vlan.. Discovery protocols do not work across a router. Which no matter if you want to a call it a vlan or a network makes no difference. "Discovery' should be possible if inbound NetBIOS (UDP/137)" Which isn't going to work if he setup vlans per his post. "Those PC-shares are situated in multiple VLAN's like PC-lan en Guests" Be it the vlan is isolated with a tag or not, makes no difference. Windows isn't going to discover a computer via any discovery protocol when they are on some other vlan/network.. The only possible way that would work is if they were running multiple IP networks (192.168.1.0/24, 192.168.2.0/24) on the same broadcast domain. Which should never be a thing, and it sure wouldn't be called different vlans. How he should be doing it is how I went over already with dns to resolve the name of his box sharing stuff via smb.. There is no need to "discover" it other than a simple query to his dns for its fqdn.

@SteveITS so finally noticed the error I was thinking in isc about lease too early.. when a client asks for renew Feb 6 18:06:26 dhcpd 94617 reuse_lease: lease age 19813 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.2.212 Just more info to throw out there - where you could consider this as log spam from possible bad acting clients. I am seeing this from a few different clients Feb 3 13:31:51 dhcpd 26941 reuse_lease: lease age 18375 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.203 Feb 3 13:31:48 dhcpd 26941 reuse_lease: lease age 18372 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.203 It's possible I introduced this - this thread got me looking at my dhcp log, and noticed was seeing log about duplicate leases on a few devices, etc. stuff was working but seemed to have some old leases handing around where a client had 2 different leases.. I think this related to how I will bring a client up on normal dhcp, and then set a reservation.. Going forward when I bring up a new client going to set a reservation will make sure delete their old lease. In going over my dhcp server I also noticed some of my scopes had lower lease time than I like. So I had adjusted them, so client would not have known this. So possible when I raised the min lease time, clients trying to renew their old lease time didn't match up to the new lease time? Also could be just wireless clients going off net and then back on or something - will have to look into the IPs seeing these to early log entries. And when they come back on they try a renew even though lease has not gotten to the 50% mark as of yet. I know that 203 is my wifes iphone (old one) and 212 is one of the new iphones (not sure which one yet) since both me and the wife upgraded our phones yesterday. I need to setup their reservations ;) My point is more to yeah you will almost always have some sort of log entries that seem like spam to you. I do believe if you can reduce it all the better, or at least understand it. Entries in a log that are of no use to you just make it harder to spot stuff you are interested in. And yeah you can have bad acting clients, and stuff not quite sure what it is can send you on a wild goose chase sometimes if trying to solve a problem. If kea is logging stuff about some subnet, as long as the client is getting an IP. Maybe with all the fancy stuff you can do with kea logging you can get it to stop logging what amounts to spam if the client is actually getting an IP, etc. edit: Ok I am just an idiot for not looking in redmine first, there is already a bug listing for this https://redmine.pfsense.org/issues/16684 So that explains it ;) And there seems to be a fix for it https://redmine.pfsense.org/issues/16682 Now have to try it out.

OP, Here. @stephenw10 and @slackie, support determined it was a hardware failure. Unfortunately, it was no longer under warranty.

@ChrisJenk Yes exactly, Quantum should be physical MTU + 14 + 4 (ISP using VLAN). I tried but rarely I got A+.

Well, after a hell of about 24 hours, where I could barely sleep, I got it to work now with a "downgrade" to pfSense CE 2.8.1. I don't know if ZFS boot verification is associated to the message "Automatic boot verification is still running, please wait...", that if I am not mistaken has to do with verifying that my paid license is ok. Although I paid for the license (and now I have 1 year of TAC Lite), the verification was failing and whoever the clever developer, just rebooted, without giving any explanations to why or what the problem was or even to mention that there an issue with the license. Long story short, the message never cleared and then the system was rebooted. I am now a happy user of pfSenseCE and probably will not venture into plus anymore. Too dangerous. thanks for all the support and the system is back running solid as a rock, as one tends to expect from pfSense.

@marcosm I am looking at upgrading my 2100 from 25.11-RELEASE (arm64) to 25.11.1600002. The pre-upgrade documentation clearly states "The safest practice is to remove all packages before upgrading to a new release.". I attempted to upgrade Nexus and got the error that I need to confirm the action with the additional error that NEXUS is vital to the system operation. Looking at System/Advanced/Nexus shows it is NOT enabled. I put the 2100 into production March, 2025 and have done 3 upgrades. Two questions: Is this 'safest practice' for upgrading versions say 24.nnn to 25.nnn and the removal of the packages is not necessary for upgrading releases say 25.07 to 25.11? Since I can not delete the Nexus package, is it still safest to upgrade to 25.11.1600002?

There was discussion of it at the time when we introduced it. See: https://www.netgate.com/resources/videos-zfs-boot-environments-pfsense-plus-24.03

Hmm, those are normal.

Yes, if the ISP device is connected directly it will cause errors if it reboots and loses link. But it would also show specific link state change logs.

@stephenw10 said in Watchguard Firebox M400/M500: We should move this to the other thread I think it's a good idea. The expansion module recommendations I made are relevant to M470 / M570 / M670, but not to M400 / M500.

OK, thanks for the pointer. I forgot about that installer ... If it were more than 10 appliances I might consider setting up PXE-booting for that ;-) but that might be overkill for now. I'll see how it goes as soon as the hardware is here, thanks all.

@stephenw10 said in CRITICAL: 25.11 has broken VIPS defined on PPPoE interfaces managed by if_pppoe: It needs something more than that patch because whilst that fixes it for if_pppoe it breaks mpd5. Understood. It would still be good to get a fix in the next significant release.

@SLRist Or at this point you can set any other subnet for LAN...at least currently it isn't used after installation, unless that's changed: https://docs.netgate.com/pfsense/en/latest/install/install-walkthrough.html#configure-lan-interface

Just updating this thread for posterity—to confirm that "no nat" is the only way (and probably the only correct way) to resolve this leaking of a private WireGuard interface address. This did not work: nat on $WAN inet6 proto icmp from [WAN interface link-local]/128 to [ISP interface link-local]/128 -> [ISP interface link-local]/128 nat on $WAN inet from any to any -> [WireGuard interface address] port 1024:65535 nat on $WAN inet6 from any to any -> [WireGuard interface address] port 1024:65535 There's a mismatch there between "inet6" and "icmp". This may work if "icmp6" was available via the webConfigurator's NAT rule configuration "Protocol" dropdown: nat on $WAN inet6 proto icmp6 from [WAN interface link-local]/128 to [ISP interface link-local]/128 -> [ISP interface link-local]/128 nat on $WAN inet from any to any -> [WireGuard interface address] port 1024:65535 nat on $WAN inet6 from any to any -> [WireGuard interface address] port 1024:65535 But I've had to settle for this: no nat on $WAN inet6 from [WAN interface link-local]/128 to [ISP interface link-local]/128 no nat on $WAN inet6 proto udp from [WAN interface link-local]/128 port 546 to ff02::1:2/128 port 547 nat on $WAN inet from any to any -> [WireGuard interface address] port 1024:65535 nat on $WAN inet6 from any to any -> [WireGuard interface address] port 1024:65535 (Note that I also needed to add a "no nat" rule to preserve DHCPv6 functionality.)

@stephenw10 Thanks again. I just need it to install pfsense. I will be using a HDMI computer monitor. Then the webgui will take over.

You could purchase a larger ssd …

@SteveITS said in Can not update - no space left on device: the future I’d do that before upgrading Before updating, upgrading, for every device you own - PC, smart light bulb, your car, printer, Phone pad and camera : These are the universal rules : Step 1 : power it down and count to 10. Step 2 : Power it back on. Step 3 : If the device has a 'filesystem' or a massive comples operatuion system like a Phone, PC, and also pfSense : check avaible space. To understand why and what happens there isn't : try upgrading PC from Win 10 to Win 11, with less then x Gbytes left on the disk. You risk to 'break' the OS on your PC, it can't boot anymore and good luck retrieving your data. Step 4 For pfSense : Get (export) a copy of the config. Now you are ready to upgrade. These 4 steps take 5 minutes max, and it's really small investment, see it as a assurance. If you don't do these 4 steps, the risk is great you loose way more time (and your data). You could recap my ramble in 5 words : "Do not test Murphy's law".