Is 192.168.50.5 the correct IP for 4c:b0:08:2a:d4:36? You might need to capture for longer to what's triggering the movement log. That Intel MAC is odd though, I expect to see that broadcast. Can you find that device? Is it some rogue router on your network?

@jarhead said in Question about Automation and firewall rules (enable/disable using SSH/API): @bmeeks said in Question about Automation and firewall rules (enable/disable using SSH/API): @andrek said in Question about Automation and firewall rules (enable/disable using SSH/API): thank you. is the appliance open for SSH to shell so I can run pfctl from another device? When you enable the SSD daemon via the GUI, it automatically opens the necessary port on the LAN. It does not open WAN ports that I remember. Pretty sure it's open on all interfaces but you would need a firewall rule to allow it through the WAN. Not that I'm suggesting that. Yeah, the daemon listens on all interfaces, but the default firewall ruleset will only allow inbound traffic to connect from the LAN. The docs I linked explain that a little farther down (and refreshed my memory).

@nerdy Consider using the pfsense Package named “SYSLOG-NG” to forward logs to ELK. There are several advantages: 1: It can monitor local files for entries and forward them to ELK. That not only means the local pfsense log files, but also package log files from pfBlockerNG, Freeradius, NtopNG and Suricata/snort. 2: Syslog-NG can speak/convert inputs to native GROK so ElasticSearch gets data in the most enriched way right up front. It also makes is easy to filter specific log entries from the monitored logfiles that there is no need to forward and store in ELK.

@cg50000p You don't need to trun off any software firewall, there's no way they will conflict. But you may have to configure both depending on what it's doing now. Don't be afraid of pfSense, it literally will just work once installed so you can plug it in, and then learn it over time but you'll still have your internet working.

@jarhead That did it. THANK YOU!!

Well it caused me to go ahead and clean up the v6 configuration on mine. I was not having this issue but I did have some things running that likely did not need to be as well as the outside and inside picking up v6 addresses. May as well keep it simple.

Hmm, so the switch sees the two VLANs bridged and complains. You could probably just disable STP on the switch. Or maybe block the STP traffic across the bridge. Or use two ports maybe? Steve

Yes, make sure WANGW is set as default and not auto.

@stephenw10 @AndyRH use intel 82574L 1Gbps NIC x2 The network is normal have 1G/600M thank you

Thank you.

@michmoor said in PFSENSE WIFI CALLING: lots of CP changes in the new releases i see You mean 22.05 as you talk about a 6100 ? 22.05 doesn't use the good old second firewall 'ipfw', as 2.6.0, but uses a new, modified 'pf' so it can also handle MAC ( ! ). It was Netgate that changed 'pf' upstream for the entire FreeBSD community 22.05 native has issues : the "one queue for all connected users" is one of them. There is a patch. Look quickly over the last 10, 20 (skip the please help posts) captive portal forum posts, you find them all. If you are a heavy (hundreds of connected users) portal consumer, then watch your memory as there is a small memory leak in the new pf code. This can't be patched, as it needs binary changes, and the upcoming 23.0x will solve that.

There's nothing built for doing that but I agree (and I'm sure many of the devs do also) the handling in that case could be far better. If you enable ACB it should still be able to write out changes there. I've tested that though. Steve

You can restore a 2.5.2 config into 2.6. The link CRL bug (https://redmine.pfsense.org/issues/13424) is fixed in 2.7 but the patch is part of the System patched recommended list in 2.6. So if you're hitting that you can simply click to apply it. Steve

@stephenw10 Hi. Thanks for the reply. Yes I confirm, I upgraded to 22.01 and then to 22.05 and yes, I modified "pfsense-utils" to set custom these value. I'm sorry, I did not notice if on 22.01 the bug was presents. Thanks antway for the good new about this bug seems to will be solved on next rel.

@njaimo ...I get it I misunderstood the "score" bit, it is not login attempts... :) Cheers

@osalj said in notifications via SMTP - every 10 seconds: What can I do to stop Pfsense from sending emails at all or not to send me an email about DDNS every 10 seconds? When a message is send, it's paced in file, the message queue, and a "smtp mail send" process is created that reads the file, sends the message, and passes on to the next one if there are still messages to send. If non, the queue is deleted, the process stops. I guess this is your issue : the message file (on disk) isn't emptied, the "smtp mail send" keep on sending the message. [22.05-RELEASE][admin@pfSense.local.net]/var/db: ls -al noti*.* -rw-r--r-- 1 root wheel 131 Jan 7 01:01 notices_lastmsg.txt -rw-r--r-- 1 root wheel 41 Jan 7 01:02 notifyqueue.messages Do you have these two files ? What is their date time stamp ? Content ? And empty queue file (notifyqueue.messages) should contain : a:1:{s:5:"mails";a:1:{s:4:"item";a:0:{}}}

Not something I've ever looked into but if Windows is choosing to use that I'm not sure what you can do. Maybe radius can indicate why it fails prompting Windows to re-try or send a list of accepted ciphers. Also not something I've had to try.

@jpgpi250 said in how to forward new entries from a specific log to a remote syslog server: @keyser @bmeeks I finally got it working, see my comments here thanks for your time and effort. Both methods will work in the Suricata package: (1) plain syslog output to the local system log by checking the option on the INTERFACE SETTINGS tab and then restarting Suricata; or (2) configuring the EVE logging subsystem to write to syslog instead of a physical file. EVE is the direction the upstream Suricata team is encouraging for logging. You can enable the logging of more information via the options in EVE as compared to the older vanilla syslog output feature. Again, restarting Suricata on the interface after any changes to its core configuration is required for the change to become effective.

It's showing it's never completed a handshake so that is not up correctly. You must have a mismatch there somewhere. I suspect your ping test was not actually using the WG tunnel. Steve