@bjurkovski said in Upgraded from 2.4.5 to 2.5.2 and having problems with config file restore on every reboot.: I wouldn't have had this problem if I had just disabled Python mode in my config before reinstalling I think this should get pinned because I run in this trouble too: If in the config, before reinstalling, the pfblockerng was in python mode then unbound is not working (he is missing the python module) and no packages can be installed because Url's cannot be resolved. So switching pfblockerng in unbound mode before save the config is the best way to workaround this issue. Regards, fireodo

@provels You're right. I noticed the issue again. After reloading Dashboard tab the scale was back to correct again. Here's screenshot before that (Left: Dashboard, Right (ok): Status/Traffic graph) [image: 1626332654403-fd08a016-fdb5-4465-90a3-c545ae435e38-image.png]

Finally I found solution on: https://forum.netgate.com/topic/164732/python-regex-list

@johnpoz There are some ips which do not resolve as they are out of dhcp range and not static or the device doesn't tell a hostname. But almost all ips resolve proper. If domain override exists with the lookup server pointing to itself, it causes the problem. Guess pfsense gets into a loop "ask itself many times" for the entries it can't resolve.

Hi, @Gertjan and @stephenw10 Thank you for your answers. Regards

I find this post absolutely hilarious. I haven't done squat with ipv6 for about the last 10 years ... and not that I needed it now I have decided that as an experiment I will provide some v6 connectivity to some of my LAN hosts cause I have a /48 from my ISP. I was actually debugging some network issues related to NDP so was running a tcpdump on my link... as soon as my subnet become routable massive portscanning traffic started flowing in from the exact same ip: 240e:f7:4f01:c::3.53802 I find this absolutely hilarious cos this was one of the selling point of IPv6, kind of a "security through obscurity" that you cannot ( or I mean you should not be THAT DUMB TO TRY) scan address ranges and this guy is not giving up since 2 years, imagine the amount of junk traffic he generated since than and just how many ips is he scanning bruh don't have anything better to do? :D

@dma_pf said in Policy Routing Rule Not Working: Diagnostic->Tables shows that SitesThroughWAN has no entries Ok, well that's a problem. It can't match anything if it's not populated. Check the resolver logs. You may have something unresolvable in there. To workaround it before you upgrade I would move that to two aliases, one for IPs and one for FQDNs, and use two firewall rules. Steve

@stephenw10 I will retest it will get back to you

It could be either, or both. What ports does Yowhatsapp require? What are you passing in firewall rule on OpenVPN? Do you see blocked traffic? Steve

@onemt said in The website (ieee.org) does not load: No clue why this happens. Serious ? I'll bet it related to : @onemt said in The website (ieee.org) does not load: I use squidguard, easy to proof : remove "squidguard" and your issue is gone. Setting up "squidguard" (squid, snort, etc) is a complex process. A lot of learning is not an option ;)

Yes, those are scripts that run via the NRPE package as I read it. Go to System > Package Manager and install it. Steve

It can wait there for a long time trying to start the Resolver if there's no upstream connectivity but it should eventually pass that even with the WAN disconnected. Steve

@perfectbake420 Firewall rules apply to the interface they enter, not exit. Also, existing states are not affected by a rule change. You need to clear the states of the specific clients/devices your new rule applies to before they will obey the new rule.

@ogghi I think I'll try and debug on the windows server/NPS side. The packets arrive at the windows server as seen on Wireshark. But nothing is ever logged on NPS. So it might be some really stupid bug here..