@dennypage The power wasn't flickering, the power was out from 10p through 1a. The nut server is not configured to turn the UPS proactively so the UPS just shuts down once the battery is completely depleted a few minutes after every client was supposed to shut down ("low battery" when nut clients are being turned off is set to 10%). I understand the behavior in the log could be explained if the UPS turned the power to pfSense off and then back on between 22:52:05 and 22:52:13 but I don't think it was the case. Based on the timestamps alone it would seem pfSense went from shutdown to boot immediately while the system remained powered by the UPS.

@tquade to be honest port scanning the "world" could be less troublesome - than an isp customer complaining about another same isp customer But sure yeah probing the world not normally a good thing ;) To be honest many an isp should be filtering fellow customers from talking to fellow customers.. But forget getting in trouble or what you should be doing or not being doing to be a good netizen. I make sure no rfc1918 traffic leaks out my wan for sure.. Just doing my part to be a good netizen.. Rarely happens but now and then I typo a address or something.. I make sure that dns for my private domain never goes outbound as well - just no point in sending such traffic that isn't going to resolve.. What would be the point other then pure curiosity knowing that some fellow isp customer has ssh open, or running xyz as their router? What would you even do with that info? I would rather not waste my cpu cycles and bandwidth finding out that info in the first place - and just not send probes out my wan.. Now if he devices on pfsense wan this 192.168.8 network - and he wants to discovery his own devices on that network. Then going to have to look into making sure ntop only discovers 192.168.8/24 and not whatever his real wan is..

@stephenw10 Call quality is fine. I’ll have a look at the logs. Thanks!

@davewh Power cycling it fixed the problem. Thanks!

@mephmanx It took a lot of work but I was able to get through this.

Minimal. Somethings don't work well (or at all) behind double NAT. Mostly things that require NAT workarounds like UPnP. Has no impact on security (arguably improves it!) and performance impact is usually minimal as long as the upstream router does not restrict the throughput. Some SOHO routers have very limit state tables for example. Steve

Mmm, that's tough because generally that means one server process. So 10G is pretty much right out with pfSense.

@stephenw10 said in Bridge blocking.: Ah, OK. Yeah that should work. Just tried it, and it works flawlessly. Thanks.

@stephenw10 thank you very much! I am working on why my memory utilization went from 3-4 percent to 11-12 percent and growing. Once I collect and compare the top info for a few days I will seek more help. Thanks for the quick responses.

Do the gateways show as down?

Thank you all, it's solved !

Mmm, it's a known issue. It's ugly but harmless. You shouldn't ever manually edit the loader.conf file normally but you can remove the duplicates. Any loader value you need to set or unset should always be put in loader.conf.local. Steve

@stephenw10 Finally got it working! On the fifth support call to KC I asked them to double check the login details with me, the password was one character wrong! I had manually typed this in to my router a year ago yet somehow the connection worked. I can only assume their modem management filled in the correct details. Thank you for your help Stephen. I'm mad it took me 5 days to get this sorted but relieved I don't have to change ISP to get it working.

@srytryagn said in Best non-Intel Quad port NICs ?: @nimrod Udate-a-bility-> If the firmware is not updated and vulnerable was thinking that it might not be a good idea to to use it for an edge device, i.e/ a very trusted firewal. Perhaps some Broadcomss or modern intel. Those are extremely rare cases that NIC needs a firmware update to fix a critical security issue. Im with @stephenw10 on this one. Stick with Intel. You will save yourself from unnecessary headaches. to your point -> do you mind expanding on that ? Is there a mitigation? Thought that was only an issue for " pro" amd and that intels had a way to shut off in bios.` There is no mitigation. Every Intel and AMD motherboard manufactured after 2006 has a embedded chip that runs modified closed source version of MinixOS that has low level DMA access. DMA access means. Full access to the contents of your RAM. Full access to your storage. Full access to your I/O devices. It can capture keystrokes, mouse movements, take screenshots...etc. It basically owns your system completely from the moment you turn it on. It boots first, so its completely irrelevant what operating system you use. Intel calls this "feature" Intel Management Engine, and AMD calls it PSP which is short for "Platform Security Processor". There were several attempts to remove ME/PSP but intel/AMD made it impossible. When your system is done with POST, CPU microcode checks for the presence of ME/PSP and makes a handshake through a custom encrypted protocol. If the handshake fails, a timer in CPU is triggered and system reboots after 30 minutes. Basically, if you somehow remove ME/PSP your system will be stuck in permanent reboot loop state until full ME/PSP functionality is restored. There are very limited number of motherboards and old laptops where ME can be fully or partially disabled. You can find more info about this here.

What do you see from Diag > DNS Lookup in pfSense? Are the clients using 1.1.1.1 dircetly for normal lookups? Steve

Just turn off IPv6 - does it work now? There you go you know where the problem is happening. But doing a directed query to 1.1.1.1 which wouldn't be IPv6 and getting a timeout just seems like bad connectivity, or slow connection, are you routing through a vpn? Are you on sat connection? You doing some odd redirection of dns traffic on pfsense? Do you have isp or other router in front of pfsense doing dns redirection?

It should be logged there if you have logging enabled on the pass rule(s) and any states have been opened. It may have left the logs already if you have a very busy WAN.

@bokolobs said in Anyrevo fanless appliance hitting >60 C, is this normal?: @nimrod I actually have an extra tube of Thermal Grizzly Kryonaut lying around. I might re-paste it if I feel adventurous. I would not do it. Although cheap, there is absolutely nothing wrong with your unit. All the issues you had so far were software issues. Just install pfBlockerNG, apply the patch and you are good to go. And thanks for the info regarding mini pc brands. This is my first unit like this. I'm used to assembling my own PCs, but I got lazy and just purchased this. It is also very difficult to get 4-port Intel NICs right now where I live. I still have a Beelink GK55 mini pc which I used as an Untangle box for almost a year, but it only had 2 Realtek ethernet ports and is no longer suitable for our network needs. I'll probably use this Anyrevo one until it breaks or gives me trouble. Or maybe I'll just build a low powered, mini-atx one with better specs if I can get my hands on Intel NICs. If you guys have recommendations, that would be awesome. Anyevo is a cheap appliance, but make no mistake. The board inside still has a Intel CPU and Intel NICs. Anyevo and other cheap Chinese brands, get lower prices by using lower quality metals for their case. Packaging is cheap. They have bad machining (rough metal), poor paint and printing on the case. They also ship their units with cheap AC adapters, cheap no name RAM and SSDs. There are no bios updates, software support, or any support for that matter. Warranty is also questionable. If you, for example, get higher quality power supply and better SSD, that unit will serve you for many many years with zero issues.

It looks like it's something in multicast routing though which is probably why more people are not hitting it. I don't see either IGMPproxy or pimd shown in your console output but do you have either configured? It could be same root cause as this: https://redmine.pfsense.org/issues/12079 It's very difficult to reproduce that issue unfortunately. Steve

Are you running that as TCP or UDP? It's hard to say from their website but it looks like it's UDP by default. That hardware should pass that without any difficulty at all. It could probably pass >5Gbps. I'd be amazed if this is not a restriction in the WAN some where. If you connect a client to the WAN directly do you see the expected 1Gbps with no loss? Does pfSense show packet loss in the WAN monitoring? Steve