As far as I can see, it seems to be self contained : https://docs.netdata.cloud/installer/#pfsense extract : Note first three packages are downloaded from the pfSense repository for maintaining compatibility with pfSense, Netdata is downloaded from the FreeBSD repository. pkg install pkgconf pkg install bash pkg install e2fsprogs-libuuid pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/latest/All/netdata-1.11.0.txz the netdata package does not seem to add extra dependencies unless I'm looking wrong but something like netdata (also like ntopng) is designed to run 24/7 I'm running it on a test pfsense in an isolated network, for now the test setup seems to run

Thanks for the help. I just added the LAN nic to the same local network to get things configured.

@stevelambert Try to change the binding in usr/local/etc/netdata/netdata.conf change bind to = 127.0.0.1 to bind to = * restart netdata : service netdata stop service netdata onestart

Ah, that can do it if there are unpopulated tables in the ruleset. pf cannot load and hence there is no NAT. Steve

Ok well if it comes back I'd check the other interfaces to see if it's ARPing there. It's not doing so there if you were pcapping on the actual interface in question. Also make sure you have all the hardware offloading options disabled. Steve

Updating to latest : See forum "Installation and Upgrades" , you'll find examples how to proceed. If the GUI is ko, access the console. Option 13. See also https://www.netgate.com/blog/pfsense-2-4-4-release-p1-now-available.html and the very important https://www.netgate.com/blog/pfsense-2-4-4-release-now-available.html

partial resolving: reapply another time changes ( saving) to records modifications... it should work at the second time. It was a WebGui config interpreter bug. ( maybe because by defaut the first field active is the proxy support one, and may the active field is tested as changed by this way and need to be valid to be registered. And so all modifications on misc options recall us "the password of support proxy info do not match..."

Nice. I expected that to work but I could also easily imagine something unexpected getting in the way. Steve

I take it the "3 emails a day" are being sent by your mail server software to alert you? If it is from random senders I would consider those phishing emails. Any mail server with ports open to the Internet is going to see a lot of attack attempts. If you have a lockout after 5 incorrect passwords they will likely give up and move on. Suricata or Snort can try to block those attempts, yes. They can be set up so if an alert is triggered the IP is blocked for the desired amount of time. Generally for in-office mail servers, we set our clients up with our spam filtering service, and in pfSense only allow connections on port 25 from the filtering service IPs. So the world cannot just connect to the mail server.

I somehow had something wrong with the Interfaces that caused it to crash, reconnecting WAN and PPPOE fixed it. I will try with the problematic onboard NIC later, the new NIC which is a em3@pci0:2:0:0: class=0x020000 card=0x10838086 chip=0x10b98086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82572EI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet works perfectly fine aswell.

I'm aware of anything specifically that changed that would cause that but it could be any number of things. You might check the ps -aux output for a single process using that. Steve

That should not happen but there can be significant delay opening the dashboard if there is no upstream connectivity. Check the system logs for errors at that point once you are able to get connected again. Steve

@evaluationcopy Hi - I have been trying for probably 10 or 12 hours to research and parse the pfsense sylog with snort data. I cannot get it to parse. Based on your sense, it sounds like you have already concluded that snort in particular this - snort[12345] is not parsable in logstash? If you know of a way, id really like to know! Thanks

The bottom line is if you need Active FTP clients behind a firewall and the services provided by the FTP_Client_Proxy service are not a good fit, pfSense is not for you. The availability of certificates has nothing to do with the fact that when a client requests a file, it tells the server where to connect to and that reverse server-to-client connection has to be opened on the client side firewall. Or firewall(s) in your case. SSH has been around for 20+ years. SFTP for 15+. They still insist on using FTP.

@joelt said in Console access: Cisco 2901 That's what you're using as a console server? That has USB ports does it recognise the 8860 console port? It also had usb console exactly like the 8860, though it probably uses a different usb/serial IC. Steve

Hi, The question is known . Check pfsense API. Not something for tomorrow, it's a huge job, and needs an entire GUI internal rewrite (like the GUI will be using also the API to handle ALL settings). HP code and passes in the arguments? A huge hassle I guess. A local scripts that read the concerned VPN section in the config file, changes, sets the Disable flag for one VPN server, and resets (removes) the same flag for another server. The write back your changes. Then a "reload_filters". Maybe you should stop the VPN server first - do what I said above, and start VPN.

Thanks @jimp for looking into this, I am happy to hear that there was actually an issue here and that you were able to resolve the issue so swiftly. I look forward to applying the fix when made available.

Thanks for the reply. I actually realized what it was a couple of hours after I posted when I saw the same error message for DHCP4. My ISP seems to be having issues lately.🤨

The ARP table page attempts to correlate entries with DHCP leases and reverse DNS resolution for hostnames. Either one of those could account for a delay.

You next question will be : my UPS doesn't shut down pfSense anymore .... (or : what was the usage of this cable ? )