@luckman212

Click on the image :

1c8c8a2b-ed5f-4dd1-8694-8be0e58350e8-image.png

I didn't test other search engines ...

edit : the link @kpa posted is, imho, the best answer ( and totally not-FreeBSD related ^^ ).

@aaronouthier There was a bug in 24.3/11 where deleting multiple rules would reorder them. There’s a patch.

But otherwise no it’s not normal at a reboot. Maybe compare config files before and after?

@aaronouthier said in Looking for few pointers getting Suricata on PFSense to talk to my Security Onion box.:

Ok, so I've been researching the topic. It seems SO has an integration for PFSense. However, the FreeBSD implementation of Syslog is not optimal for this purpose, as mentioned above.

Although I am comfortable with CLI Linux, I am effectively a Newbie with regard to BSDs.

My next question is: What would be the least invasive method as far as the PFSense Box to export just the Suricata logs? I believe I saw an option to log to a Unix Socket. Would that be helpful coupled with something like Netcat? I'm not necessarily looking for help with such a feat, just wondering if such would likely be fruitful, or am I just chasing the infamous wild goose?

I recommend exporting the EVE JSON log as that will be the most comprehensive. To export to a UNIX socket, change the EVE OUTPUT TYPE setting to UNIX socket. You will need to manually create the socket and give it a name. It will be up to you then to "receive" the socket data stream and redirect it elsewhere (seems you want it remote for your case to Security Onion).

The repo seems to be back online today Jul 19th, I was able to complete the fresh install.

@werter
Благодарю за ссылки!
Поток негатива на netinstaller уже пошёл.
Задушат pf CE походу...

@qinn
Sent him an email Dan an email to the address on his site.. Not sure what is happening, my Teams stopped working. Disable it/turn it off and the problem went away.

@pfsvrb
this was an issue on my system also..
Target & Interval were default set to 0..
change to 5 & 100 fixed it

Do you see anything blocked in the firewall logs?

Connectivity from that host is otherwise good?

Is it using the same DNS server(s) when configured statically?

Ultimately I would run a packet capture when you run the failing task and see what's actually failing there.

@Lars_ said in How to update No-IP IPv6 (dynupdate.no-ip.com does not have an AAAA record):

@SteveITS Determined testing pays off. It works now 🎉

Same for
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myip=%IP%
with option "HTTP API DNS Options = Force IPv4 DNS Resolution" enabled.

I was actually quite close. The solution is to update the AAAA record using IPv4:

Service Type: Custom (v6)

HTTP API DNS Options = Force IPv4 DNS Resolution

Update URL:
dynupdate.no-ip.com/nic/update?hostname=thisismydomain.ddns.net&myipv6=%IP%

Note: It has to be &myipv6=, not &myip=

Is this something that makes sense to be implemented in No-IP (v6) and No-IP (free-v6)? It would not work if IPv4 DNS resolution isn't available, but I guess that is not very common in the wild.

Haven't found a way to tag this thread as SOLVED.

This solution worked for me!

I managed to resolve my above issue and for anyone ending up with the same question:

My issue was caused because of a colleague who added a floating rule, rejecting traffic coming form another alias with logging disabled on that rule. Unfortunately that alias contained a different FQDN that resolved to the same IP of the removed FQDN.

What is the important lesson here:

Apparently the PF box handles floating rules AFTER interface rules. And since logging of that floating rule was disabled, the firewall log logged the allowed traffic from the interface rule, but blocked the traffic afterwards based on the floating rule with no logging! You end up seeing an allow in your log, but it is blocked in the end!

This must be a culprit some else will face one day or another :)

I'm experiencing this issue as well. I've been watching for patches and new releases to see if this is resolved.

@JonathanLee https://github.com/pfsense/FreeBSD-ports/pull/1420

I have tested this and it complies I do not know if anyone else has the ability to test this on pfsense dev mode but here is the pull that sets the Makefile to use Squid 7. I took a long long time to compile and it removes Auth for SMB_LM

If anyone wants to test this out

https://github.com/pfsense/FreeBSD-ports/pull/1420

I did get it to fully compile with the adapted Makefile they disable SMB_LM that has been removed

@bmeeks So after upgrading to the newest PfSense 2.8.0 everything is now working like a charm!

Suricata no longer seems to strip off tags like it did before! Which means I can now use my network segmented by VLANs and still use the benefits of Suricata Inline IPS! Very niiize!

I checked in the Alerts section and it is indeed generating the correct alerts from the different VLAN sections, I put Inline IPS on the parent interface of all the VLANs.

I assume this is because the FreeBSD version is also updated with the new PfSense 2.8.0 version?

Because before, as soon as I selected Inline IPS mode, my entire VLAN tagging would break and nothing was reachable until I switched back to Legacy mode.