@SteveITS Thanks I finally go it resolved! It sure would be nice to have a search box on the dashboard ;)

@louis2 said in Big issues related to Firewall logging.: [ . . . ] as the coordinator here and representative of Netgate Netgate employees have an official "Netgate" forum badge next to their handles. See @jimp's profile, for example.

Dude.... I feel dumb. There's a "Remove Shaper" button RIGHT THERE! :-) Clicked it, rebooted and so far the error has not returned to my notifications area. I don't expect it to either, since all the lines about queues are gone from /tmp/rules.debug. Glad I came here. Thanks for hand-holding me along, @SteveITS.

Hello, Same issue here, a "gateway monitoring" rule blocks IPv6 gateway monitoring. Removing the monitor address from the gateway configuration and re-adding it causes the rule to disappear and monitoring works again until next interface reset. The issue began after upgrade to 2.8.0 and is still here in 2.8.1. Best regards, Ed

…and for a couple years, give or take, MaxMind has required the additional field/info to update so the geoIP data probably isn’t updating.

@DouggaDit said in pfSense blocking all DNS: The firewall is simply unstable. Integrated network aliases don't function. The firewall simply doesn't work. Rules to allow all on specific ports appear to be the only type of rule that work consistently. Attempting to narrow the 'allow' to specific ip addresses or networks fail. User defined and system defined interface-related aliases don't function. This forum is not a good use of my time. I assume the silence is simply bait to get people to switch to paid support. Safe to file this one under did-a-derp-and-kept-digging.

Fyi, I had previously opened a ticket with the website administrators but have had no reply... until today, after I started this chat. So... they just told me that they're already aware of the issue and it probably has to do with the recaptcha quotas. This website is used by many people so, they probably will have to upgrade the plan. I'm sorry to have taken your time on this, and thank you for that.

@Cloufish there is a difference between traffic that would go out your wan interface to get somewhere, and wan address as your destination. It would rare that a client would actually ever try to go to your specific wan address. Your wan address is just that the IP address on your wan interface, say 1.2.3.4 if public. your wan net is just the network 1.2.3.0/24 that your wan is on.. Some client to go to an Ip on the internet say 5.6.7.8 or 8.8.8.8 would never have your wan address or wan network as the destination. The destination would be those 5.6.7.8 or 8.8.8.8 Ips

@SteveITS said in Rules not blocking guest network from firewall or other VLANS: because something doesn’t match: source/interface, port, destination. Completely agree - but with the rule he is showing ipv4+6 any any to any firewall IP.. It would clearly match trying to open up the webgui of pfsense. But clearly it shows it has never triggered with that 0/0 - so 2 things that come to mind is there is a state currently open that is allowing the traffic even with the block rule added. Other is there is a floating rule that is triggered to allow it before that rule would get evaluated. edit: other thing would be he is not actually talking to pfsense via that specific interface, and the interface being used has different rules that allow the access. So would like to see floating tab rules, take a look in the state table. Like to see clients IP address.. With that rule in place a client on the guestlan subnet should not even be able to ping the pfsense guestlan IP 192.168.30.1 let a lone access the gui.

@RKiFkRyCevGvpLeXMove said in Firewall blocks explicitly allowed traffic: pfSense has added IPv6 versions of the aliased IPv4 IPs, even though IPv6 is disabled in pfSense. having pfsense not talk ipv6 doesn't stop dns from resolving a fqdn to a IPv6 address (AAAA). If you create an alias that says resolve dns.whatever.tld and it has A and AAAA (ipv6) records then that is what it will resolve. Resolving something to IPv6 doesn't mean you can talk to it on IPv6 if rules do not allow it.

@Overcon said in Inverse Block Rule: I want to block the WWW VLAN from all access to the LAN interface (container), except to the DNS servers located in the LAN. So the rule is placed in the LAN interface, or I believe it should be. No. The rule has to be defined ever on the incoming interface. So if you want to block access from WWW to LAN, define the rule on the WWW. Remember that a block rule (even with invert mach) doesn't pass any traffic. So you need to add a pass rule below of it to allow DNS. The only kind of rules, which you can define on the outgoing interface, are floating rules.

@nirmelamoud said in Nat stop working after certificate renewal: I See access denied (its 403) There is no possible way pfsense could do that - and when I go to the IP and see your website with pictures via https - I just get a timeout I get no 403, a 403 is telling you you can't got there.. Not the firewall. And if your seeing traffic to 443 blocked in the logs - why/how could it be sending a 403??? You understand when you block in a firewall all it does is ignore the traffic.. So your client just never gets an answer. If you are not going to actually show us your rules, rule order matters, maybe you have it set for udp or something, nor do any off the basic port forwarding troubleshooting that takes all of 30 seconds tops to do - nobody is going to be able to help you.. Go to can you see me . org - send traffic.. Sniff on your wan do you see the traffic come in.. Do you see any sort of response, ie a Syn,ACK? If you see no response, now sniff on the lan side do the same test do you see pfsense send on the traffic.. If you do then pfsense did its thing whatever is not working for you has zero to do with pfsense.

@eeebbune System > Routing > Gateways has a column for Monitoring IP. It defaults to the WAN gateway. If you change it to another IP like 8.8.8.8 then a static route is created for 8.8.8.8 to only use that WAN. (see Diagnostics > Routes) If that WAN is down then you can't get to 8.8.8.8. Because if pfSense could get to it, then it wouldn't know that WAN as down.

@SteveITS They were not existing connections. In fact the tablets involved were just powered on and connected to the existing WiFi network with the existing firewall rules. It is just that the rules had mysteriously vanished(or anyhow that is exactly how it behaved).

figured it out, it looks like HAproxy is not letting me edit some system setting as when i log in with ip address all works as it should could it be my certificates?

@luckman212 said in IGMP IPV4 endless log-messages / rules not working :(: I assume Local is an interface group you created? Yes, sorry I didn't point that out. Yes, I use a "Local" group for controlling a bunch of stuff such as ICMP, IGMP, DNS, NTP, etc. Btw, yes you are correct IGMP is only used for IPv4. It's a habit I guess (and a poor one at that) that I casually choose IPv4/IPv6. For IPv6, ICMP/MLD is what is actually used, but I believe a rule for this is not necessary because the MLD packets do not have the router alert bit set (at least on my Cisco switches, YMMV).

To filter incoming traffic by IP and URL on pfSense, use firewall rules for IP blocking and a proxy or web filter (like Squid) for URL control. pfSense handles IP filtering natively, but URL filtering requires extra tools. For consistent outbound IPs useful in more complex setups you can check here. LightningProxies offers IPv6 proxies with 2× /29 subnet pools, unlimited bandwidth and threads, HTTP/SOCKS5 support, sticky or rotating sessions, IP whitelisting, and global coverage.

I thought that issue is resolved, but I just started to get same error: ``` [15-Aug-2025 07:21:41 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528 [15-Aug-2025 07:21:50 US/Eastern] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 20480 bytes) in /usr/local/bin/kea2unbound on line 528e_text Note: pfSense is set to Python mode in DNS/pfBlocker.

@Bob.Dig said in After upgrading to 25.07 (6100) Strange empty firewall rules blocking UDP / no port: @conover Probably the same way you do it for "the new" IGMP logs, you create a block rule if this should be blocked, it is blocked right now, and make it no-log. Good point - thanks (wasnt aware of the new "IGMP rules"). But the log for the blocked rules do not say for which UDP port(s) the blocking is.