Agree That bug really does make alias much less useful. Two example I currently use aliases for which will fail with this bug White list for remote access to work server from periheral sites. The laptops will roam between sites Peripheral site DDNS FQDN Peripheral site relatively static IPv4 addresses Laptop 1 DDNS FQDN Laptop 1 DDNS FQDN White list from a VoIP supplier with redundant servers in multiple cities. During fault conditions the supplier redirects traffic to better functioning servers in another city city1.Voipsuppler.com city2.Voipsuppler.com city3.Voipsuppler.com city4.Voipsuppler.com city5.Voipsuppler.com city6.Voipsuppler.com city7.Voipsuppler.com city8.Voipsuppler.com Imo The variable FQDN component of an alias should be completely recalculated from scratch then combined with the constant (explicitly specified) IPs each time. After which only changes from the current IP addressees written to filterdns to update the firewall filtering.

I had difficulty making sense of edits after the system has locked up because old entries are retained and test reproduction more difficult. The other reason I have not focused on it is it tends to demonstrate the bug can be made latent so is bad not good. To explain For me the bug initially occurred in a production unit. I incrementally update the configuration over years. One update resulted in me going over the total alias entry limit for alias with a FQDN. As old entries and other alias tables are retained after editing an alias, the system continued to work well. Months later I had a prolonged power failure resulting in a pfsense restart. The restart forces a full alias rebuilt but now the failed alias entries were not restricted to my edits 2 months earlier, other more critical entries were omitted. Which presented as failure of my main incoming VoIP supplier to register on my PABX. As a result I have focussed on behaviour on device restart as I don't like latent failures.

The current pkg version for 25.11 is 2.3.1. Perhaps something happened during a previous upgrade? I think 1.3.14 is from before the FreeBSD 16 update. You might need to reinstall packages or roll back to a previous BE and try the upgrade again.

@Gertjan Thanks for taking the time to respond here For some context: I manage the gateway/firewall remotely for an IT admin who reports the issues to me. Not really sure what was going on at the time. The fact that the portal landing page was not appearing across the entire network but then would appear again after I would login to pfSense and hit 'save/Apply Changes' in the captive portal settings, remains a mystery to me. At the time the version was 2.8.0 but I upgraded to 2.8.1 as soon as I could. It seems stable now but will report if the issue comes back.

@CrKlom3 I do not recall attempting to boot a device from USB with both the eMMc and NVMe drives removed.

@dennypage Nicely done sir!

@RNM-0 Thanks for your comment and sharing your fix. Unfortunately I don't want to take down pfsense and downgrade versions. I'm currently fine at the moment since I'm using Tailscale and that works. I also fixed the other crash I was having with pfblocker by changing a line code that wasn't pushed out under this version. Hopefully the stable release won't take too long to release but it appears there's still some open bugs that need to be fixed before that happens, and ironically, both the pfblocker and wireguard issues aren't on that list of bug fixes.

No worries. Yeah that appears to be a bug in mpd5 that some modems hit.

@vicking said in No blocks on IP: Is it a bad idea to have the action set to deny both instead of inbound only? Question is squarely for admin. Per the infoblock which explains, in part, the "Deny Inbound", "Deny Outbound", and "Deny Both" actions: 'Deny' Rules: 'Deny' rules create high priority 'block' or 'reject' rules on the stated interfaces. They don't change the 'pass' rules on other interfaces. Typical uses of 'Deny' rules are: Deny Both - blocks all traffic in both directions, if the source or destination IP is in the block list Deny Inbound/Deny Outbound - blocks all traffic in one direction unless it is part of a session started by traffic sent in the other direction. Does not affect traffic in the other direction. One way 'Deny' rules can be used to selectively block unsolicited incoming (new session) packets in one direction, while still allowing deliberate outgoing sessions to be created in the other direction. In other words: When set to "Deny Inbound", incoming connection requests from WAN hosts are blocked and therefore no state will be created. However a LAN host can still establish state to an otherwise listed IP. If set to "Deny Outbound", outgoing connection requests from LAN hosts are blocked and therefore no state will be created. However an incoming connection request from an otherwise listed IP to an 'open' WAN port can still establish state. If set to "Deny Both", both incoming connection requests and outbound connections requests are blocked and therefore no state will be created regardless of connection direction.

Добавил Opencore-iso - a properly configured opencore dvd iso for proxmox ve and qemu_kvm support mac os x 10.4 to macos 26 Действительно рабочий вариант завести макось на pve на данный момент.

@patient0 I’d run into/posted this a while back and it was driving me nuts. Good to hear FreeBSD fixed it. Or accounted for it.

@timbopoise said in OpenVPN instructions for ubuntu server behind router firewall and no ufw: Or am I missing something? Setting up a VPN behind the router, instead of on it, causes routing issues. Devices on your LAN have to learn somehow what the route to the other end of the VPN is. DHCP won't do it. If the VPN is on the routing, it sorts things out as usual.

@johnpoz Thanks for your help with knowledge about openwrt

@viragomann Danke für deine ausführliche Beschreibung. Das was du beschrieben hast, hört sich nach vielen Änderungen in den Einstellungen an. Ich hab mich dazu entschlossen die beiden VMs zu entsorgen und alles nochmal auf physischen Rechnern aufzubauen. Ich habe etwas Angst, dass es zu Problemen bei anderen VMs kommt wenn man so viele Einstellungen ändert. Danke nochmal für die Hilfe und viele Grüße.

@keyser I could also change the connection between the affected sites to Wireguard. The downside is I end up with two VPN Technologies for Site-to-Site connection too, cause not all my devices are Wireguard capable. I also have to evaluate how Wireguard interact with dynamic routing running FRR and especially BGP. It might be worth looking more closely into this and switch to Wireguard where possible. The lack of IP fragmentation support with VTI IPsec is also annoying. I suspect a sort of regression causing this issue. If we're lucky it's due to changes of default configuration and this may get fixed on the fly. But so far I haven't spotted any, when comparing IPsec related settings between 2.7.2 and 2.8.1.

@patient0 I'll try. Thanks ;)

Hi, I just completely removed my pppoe interface after switching to the new if_pppoe and it started to work after recreating it! Only thing I noticed is that with the new if_pppoe the device takes longer to obtain an IP/connection after a reboot f.e. compared to the old implementation. But everything is working now, so this can be closed! :)