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.

@stephenw10 Exactly, what I failed to mention in my post (because I'm an idiot) was that this was an internal pfsense vm. Once I added the second interface, it expected me to access it from the LAN interface, which I was not doing. Thanks!

@smokey-de-bone Hey Smokey, these are great questions. We will be using the emails that are put into the survey fields directly for contact and drawings It does not matter which email you submit. They don't necessarily have to match, although we prefer if they do. In terms of it potentially sabotaging your drawing chances, it won't. As long as you are not submitting the survey multiple times with different emails we don't have a preference of which email you use as long as it is valid and can receive emails. I totally understand your concerns. We plan to use the information provided within the survey directly to contact and announce winners. That being said, we will be in contact with you, or anyone else who wins, after we draw names. That will take place long before the January Newsletter so you, or anyone else, can let us know what level of publicity you are comfortable with. We tend to go the route of first name last initial (e.g. Smokey B.). I hope this has clarified things for you. Happy New Year, Andrew

@sven72 just edit to be your network if its not already... Doesn't really matter if you don't have a unifi router to manage what is in there. All you need is the vlan only networks so you can assign them to your ssids

Yeah, the Switches menu is there to configure the physical switch IC built in to some Netagte devices. It's not a software feature that can be applied to any random 3rd party hardware. Steve

@amostil just so you know you will need console access to do the clean.. So make sure you have that setup before you attempt. And for sure take a backup of your config. It really is only a few minutes to do.. https://docs.netgate.com/pfsense/en/latest/solutions/sg-3100/connect-to-console.html

Yeah you can't test that with ping like that because the route-to rules will force anything sourced from the WAN via the WAN gateway. But even if it didn't that only tests routing inside pfSense, which should work by default. An alternative to adding routes on the clients is to add routes to the upstream router so traffic from clients is sent back to pfSense but that is a classic asymmetric route with all that implies: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html A VPN will allow it even if you don't really need the encryption there. Steve

@pinballwiz Appreciate the feedback. My take away from the post thus far seems to be the following: Allow the admin net outbound WAN access but use a dedicated OS/browser for admin work. That was pretty much were I am, so it is good to get some validation: In my current setup I'm allowing outbound WAN access to the admin LAN (during working hours) and using a Linux laptop dedicated only for admin work (non-root account of course). I keep it updated/patched and it also runs the Unifi controller software for management and firmware updates of Unifi equipment.

@misinthe said in PfSense blocking Unifi Updates: I didn't assign the PfSense DNS address to the WAN on the UDMP doh ;) hehehe glad you got it sorted.