@thearm Glad you figured it out. I ended up going full Omada so I haven't had any issues like I did before but obviously couldn't chime back in with any experience.

@timm_zahn said in Unbound 1.13.x in pfSense Plus 21.05.x: uncheck the DHCP Registration box Alternately, making the lease time longer should expand/delay the restarts. DHCP renewals occur at half the lease time.

There have been some bugs in the past that could present like that but nothing recently. If it was failing to re-connect I would expect to see an error logged. Steve

Might just be how your link behaves then.

You are running thing on the firewall directly? And the application itself does not support binding to a specific address? Something that runs as a proxy and does allow binding to one source IP might allow that. Not something I've ever tried though. If you ran it on something behind the firewall you could just policy route it. Steve

@stephenw10 Perfect. Thanks for all your help. I think I have it mapped out in my head how to solve my problem. Just need to read some pfsense code to fill in the details.

@stephenw10 yeah thats what i thought, don't know why i didn't ping the whole route initially so apologies for that, i'll play on the cisco side now lol

@stephenw10 well I disable darkstat, even removed it. It did nothing. I can't see anything else packages wise that would cause this problem as I think I only really install darkstat, and cron... I found the problem. I had a freaking traffic shaper! A while nack I was fiddling with trying to get a level balance of all primary devices. Once I disabled this I could get my speeds. All that for this!! [image: 1641237191277-screen-shot-2022-01-02-at-2.26.59-pm.png] well it was a good deep dive I guess, and I sure know what I sohuld be looking for in the future. Thanks to all Guy

Hi, So you are saying that "reordering you FW rules" then putting them back the way they were fixed you issue with not being able to access the internet after the update to 2.5.2? MP

@stephenw10 It is. So here's my progression thru firewalls. I started with Untangle on a pc with multiple NICs. Then I moved to the ALL-encompassing Unifi network with Pro 4 USG, 16 port POE switch, 24 port switch, and several AP's. When they were hacked and people started shedding the USG for other options I returned to UNatngle and bought the U150. However, I had issues with networking rules not behaving. I had a WatchGuard XCS570 laying around so I put pfSense on it and it's been running beautifully until today. That's my journey and I'm not repeating the mistakes I made in the past. PfSense works, it does exactly what I need it too and I am grateful for that. Thanks again!

Well it depends who's using it. If your users are accessing Facebook and demand 99.999% uptime then maybe hold off/ But I have been using it home as my edge device (22.01 at least) for months now without any real problems. Reinstalling and recovering is relatively trivial for me though. Steve

@perjoh91 IP Passthrough?

Makes sense, thanks! I was thinking somehow the operating system was shutting down the NIC, but I see now this is likely a hardware problem just coincidental with my pfsense upgrade. Will attend to it tonight when I get back, thanks again guys!!!

@stephenw10 Yes after restarting I am not seeing 60% of CPU utilization. OK thanks I will stop the ntopng and than check if this work than I will find any way around for this.

So I decided to update first. 2.4.4 would not update straight to 2.5.1 or .2 so I had to update to 2.4.5 first and then switch to 2.5.2 stable and now pfsense is running on the latest version without issue during the update process - and all packages are back in without issue, either. The problem still persisted. After looking at my new 2.5.2 DNS Resolver logs which are much more verbose I saw; Jan 1 22:08:45 unbound 40175 [40175:0] debug: cache memory msg=66072 rrset=66072 infra=551192 val=119453 Jan 1 22:08:45 unbound 40175 [40175:0] debug: close of port 46221 Jan 1 22:08:45 unbound 40175 [40175:0] debug: close fd 22 Jan 1 22:08:45 unbound 40175 [40175:0] notice: Restart of unbound 1.12.0. Jan 1 22:08:47 unbound 40175 [40175:0] debug: duplicate acl address ignored. Jan 1 22:08:52 unbound 40175 [40175:0] info: implicit transparent local-zone . TYPE0 IN What i did was change my search terms on google slightly to 'unbound restarting' and another previous post showed up here: https://forum.netgate.com/topic/153913/solved-unbound-stops-resolving-intermittently The solution in this article was that pfsense was restarting unbound for each new DHCP request or something like that and when you are running pfBlockerNG like I am with LOTS of blocked URLs/IPs the unbound restrt can take more time than anticiapted leading to DNS issues and timeouts. Unchecking 'DHCP Registration' in the DNS Resolver settings just above the OVPN checkbox as mentioned in the above posting seems to have solved it for now.

@dma_pf said in Logging URLs: PfSense has no built in functionality to do automated reverse DNS lookups for traffic on an interface. Even if you do the reverse - that is rarely going to tell you the fqdn used to access that IP.. And for sure not the full url. Even in the days before CDN, a site hosted on specific server most always hosted multiple sites via 1 IP.. and the reverse of this IP might be something like serverXYZ.hostingdomain.tld This PTR for that IP might tell you the name of the server the site is hosted on, it would not tell you that you went to www.funstuff.com ;) and that server might host loads of other stuff like not.funatall.net etc.. But yeah your correct the only thing the firewall/router part of pfsense would know is the IPs and ports involved in the conversation that it either allowed or blocked. Now the dns part of pfsense would know the fqdn you asked for to find that IP.. But again it wouldn't have a clue to the actual full url being requested www.funstuff.com/whatIwanttosee/index.php etc..

@elodie80 said in L3 Switch and pfSense design advise: @johnpoz Still my question remains: why pfSense is allowing sloppy states and the anti-spoofing rules are not triggered with my previous setup for LAN <-> WAN traffic ? I see no difference in the firewall states at all ! Well, finally i found the topic answering my only real question in all this discussion https://forum.netgate.com/topic/142983/how-does-antispoof-in-pfsense-work So, it is by design and explains why my setup is working without any issues in near 2 years. The anti spoofing rule is never triggered here on the transit interface because I do explicitly allow internet traffic on this transit interface from specified (or any) subnets Despite being uncommon and that it would be broken on other firewalls, pfsense design of anti spoofing rule gives this flexibility Hope it can help other users that for some reason do not need a dedicated DHCP server

@courtalj For future viewers: I made a duplicate post on Superuser and am maintaining my configuration there: https://superuser.com/questions/1672350/pfsense-cincinnati-bell-fioptics-iptv

I've never tested that, or any of the many clones of it, myself but assuming the hardware itself is good I would expect it to be fine. Or course I'd rather you bought a Netgate device. I would expect that to pass 1G for firewall & NAT at least. It looks like your requirements are for more than 4 subnets/interfaces so you would need to use VLANs and that requires a managed switch. Steve

@ninthwave Beginning with 2.5.0 pfSense also allows you to renew the certificate in the web GUI in System > Certificate Manager > Certificates.