I see. I found that one. But thought it odd i couldn't find it on the dashboard, can show individual temps, so why not usage. Was sure i was just looking in the wrong places.

@bkhiatt One thing to check is the DHCP lease, to see if it's being renewed, but given your description that doesn't sound like the issue. Can you ping the gateway when the connection fails?

@guardian said in Certificate Question: Sorry, I don't understand this [image: 1598516212016-9d2889ce-108a-4052-b3f4-0fe0f9abdd88-image.png] One of these reset the GUI access to http. The manual will tell you more. @guardian said in Certificate Question: IIUC this is only if the last configuration was http It must be the last setting change, the one you can cancel. If you change from http to https, and you lose access because https won't work for you, you loose contact with the GUI. Rephrase that : you loose the ability to make changes ^^

I'm US timezone - CST..

@EagleGC You have to have the Procurve switch plugged into the SG-1100 LAN network, which it looks like it already is. Then, the Nest wifi router should be in access point mode, then plugged into a switch port on the Procurve switch. This process will put them all on the same notwork. The Procurve shouldn't "hand out" any IP addresses, you should set it up to NOT offer up IP addresses. Unless, you've got a special reason to do that. Jeff

Doh! Test Port indeed.

I would suggest you probably don't need 8GB in there: Memory usage 3% of 8006 MiB If there is any doubt over any of those DIMMs, remove them. Run a few cycles of memtest. On a 12 year old system though it could be failing in any number of ways. Steve

snorby is old and abandonned ... it's nearly impossible to install on last debian with the ruby crap (dependency problems) ... But docker save the day ! it can install old crapy library on last version of server ;)) with docker, snorby is easy to install AND you can remove old ruby crap in one click if not needed anymore ;) Ok i will go with the ELK thing ... i will learn something at least ... thanks for your link ;) i will look ;) have nice days ;))

Hi, pfSense has a build in VPN server for remote management, and, why not, give access to your LAN based devices (if these accept remote connection). VPN became lately a total buzz word ... I advise you to look at the VPN related video's from Netgate (they have a Youtuve channel with every subject explain step by step). IDS : to reduce a long story in two words : forget it. If you insist, first, use your favourite info source, make your self very comfortable (because this one will last for days) and get to know what 'SSL' (TLS) really is. Now you know that IDS was fun, in the past, when all traffic was travelling 'in clear' - these days it's all encrypted : only most DNS traffic is still visible, and even that changes these days. mails, web access, SSH, whatever : it's encrypted in a way the Mossad, NSA en KGB - or whatever these guys are called these days - can't access it - not without throwing a multi billion installation on it. And yo want to IDS/IPS ? Still, please, I'm just trying to make you understand what needs to be done. Do not believe my words, again : look up the (some) details. DMZ : that was - on of - my boys dream : hosting my web/teamspeak/mail server. It took a moment or two to understand that I would be needing a something called a DMZ. A couple of clicks later I understood that the off the shelves basic ISP router wasn't up to the task. To day, ISP router let you set a .... DMZ ..... IP ( ? !!?). Or, a DMZ is a separated ... isolated ... network like 192.168.10.0/24 NOT 192.168.10.20 (an IP), although 192.168.10.20could be the IP of a web server that operates in the network 192.168.10.0/24. pfSense let you create more then one LAN type interface, and it will be called OPT1, OPT etc. rename them in "Pincky" or "DMZ" and you're done. The rest of the setup is : create firewall rules that enforces a typical DMZ type of operation. See https://docs.netgate.com/pfsense/en/latest/book/intro/interface-naming-terminology.html#dmz Or a good Netgate Youtube video about the subject. A DMZ network has one or more NAT rules (IPv4 still exists these days) that let Global Internet user actually visit - contact - connect to - you server type devices, situated on your DMZ. Finally : I decided to create my own DMZ in the middle of world's biggest "MZ " The internet itself. Like everybody else. A motivation was also that hosting servers behind a ISP line normally just plain s*cks ("big" dwonload, but small "upload"). I rented dedicated servers on the Internet to host my servers. The most incredible thing is : you won't be bothered with firewall rules any more. Just the servers apps like apache2, nginx, postfix, bind, teamspeak, etc. Mastering these will eat up a part of your actual live time (be warned).

@robinsonjas i have a same issue if you find something please let me know. thanks

Or maybe it's something more. I can't finish installing packages. It always stops at "Writing configuration... done." After a reboot I'm able to install the next package. Just very wonky ever since going from 2.4.4 to 2.4.5. The config.xml should be compatible.

For starters I wouldn't allow camera access from the public internet in the first place... If you want to view your camera's while your outside your network - vpn in... And then just hit them via their local name or IP.

Thanks guys, these are quite old patches, that are now included in the build I currently have which is 2.4.5-p1, I will make a backup of the files, then click the delete button, and run a diff afterwards to verify its ok. :) A patch I will still have on has already been accepted and pushed in to 2.5 so that will be one I remove in future as well.

Open a feature request here if there isn't one already: https://redmine.pfsense.org/ There may well be somethinh covering that open though Steve

Yes, the ntpd daemon is not the same as the ntp client. Yes, the server listens on all interfaces by default but that's not a problem unless you are allowing ntp traffic into WAN with a firewall rule. Steve

@stephenw10 Thank Steve for your reply. Switch 2 was connected to igb2 and was not communicating. DHCP works correctly for both vlan1 and vlan67 on Switch 1, which connects to igb1. I had added rules to both LAN (bridge0) and WiredLAN2 (igb2) to log any rejected events but there were nothing when Switch 2 was plugged in/out igb2. Worst still, I started to observe about 0.5% errors out in LAN interface even with igb2 open. Snort was not reporting anything on LAN under the bridge config. These 2 factors are enough for me to pull back from this bridged config. Thanks again for your advice anyway.

@stephenw10 said in Tagged & Untagged traffic on a LAGG interface: There is a while thread on here about a switch that does just that. I have one. That is a well known defective switch. TP-Link had the same problem with an access point as well. I haven't heard of that happening with any other brand. Again though, if you're running VLANs on a LAN, you're still going to need untagged to talk to many devices that do not work with VLANs. BTW, you can do what I did with my TP-Link switch. I configured it as a data tap, where that tagged VLAN problem is not an issue.