@SteveITS All back to normal. And the fix is really simple. I did a restore of my config and everything was back working again... Thanks again.

Hi @Finger79

have you found any information about it?
For me it looks like PFsense itself does also not support RadSec as it is defined in RFC from 2012. Nevertheless only a view vendors support it at all.

Maybe this changes after the Radius-blast issue.

br
Thomas

@kprovost Good to know, thank you.

@Gertjan your instruction is make sense to me. I already applied that too except turn on/off ssh via GUI when needed. That's another tip. Thanks you so much.

Suricata by default places the physical interface in promiscuous mode, so all traffic traversing the physical interface is seen by all Suricata instances running on the physical interface. That means there is no benefit to creating separate Suricata instances for each VLAN, because a single instance will see the traffic from all VLANs.

You can, to a limited extent, tailor how a given Suricata instance responds to traffic by using customized HOME_NET and/or EXTERNAL_NET variables and making sure all the rules you are enabling use the $HOME_NET and $EXTERNAL_NET conditionals in the rule text.

@buggz I second this. It would make things much easier than enabling the FreeBSD repos, if that still even works. I might end up giving it a whirl with one of my internal fws. I've also considered the syslog route but the agent seems like it may provide more info/customization etc.

Thanks for all the replies.

I ran the upgrade in the command line

pfSense-upgrade -y

and am on 2.7.2 now.

All packages seems to be populating again.

@wgstarks said in Crowdsec finally comming to pfSense:

@mmetc said in Crowdsec finally comming to pfSense:

@wgstarks said in Crowdsec finally comming to pfSense:

[24.03-RELEASE][root@heimdall.dahoney.me]/root: pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3-1.6.2/crowdsec-firewall-bouncer-0.0.28_3.pkg Fetching crowdsec-firewall-bouncer-0.0.28_3.pkg: 100% 4 MiB 3.8MB/s 00:01 Installing crowdsec-firewall-bouncer-0.0.28_3... pkg: wrong architecture: FreeBSD:14:amd64 instead of FreeBSD:15:amd64 Extracting crowdsec-firewall-bouncer-0.0.28_3: 100%

If you click "Assets" on the release page you will find the archive for your version

https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3-1.6.2/freebsd-15-amd64.tar

Download, untar and then pkg install in the right order.

Also not sure what the commands are to download, untar and install since I’m pretty sure the links will change for the untarred files.

Tracked down the answers for myself.
To download-

fetch <link to tarball>

To untar-

tar xvf <name of file>

Install commands-

# setenv IGNORE_OSVERSION yes # pkg add -f /root/abseil-20230125.3.pkg # pkg add -f /root/re2-20240501.pkg # pkg add -f /root/crowdsec-firewall-bouncer-0.0.28_3.pkg # pkg add -f /root/crowdsec-1.6.2.pkg # pkg add -f /root/pfSense-pkg-crowdsec-0.1.3.pkg

Install whitelist-

sudo cscli parsers install crowdsecurity/whitelists

I deleted the originally installed pkg so re-registered-

sudo cscli capi register

And re-enrolled-

sudo cscli console enroll -e context clzeha7k80004l6087uikulpm

And then reloaded the pkg-

sudo service crowdsec onereload

Still no crowdsec package in package manager though. Maybe that will get fixed later???

Hi,

there is another problem with LCDpros 0.12_1 (beside the increase processor activity since the update 12-13.05.24) when there is a Gateway latency problem or the WAN gets unexpectedly down,

Aug 6 04:28:48 rc.gateway_alarm 23648 >>> Gateway alarm: WAN_PPPOE (Addr:217.xxx.xxx.xxx Alarm:0 RTT:9.355ms RTTsd:.223ms Loss:5%)
LCDProc is flooding the log with this:

Aug 6 04:30:03 php 25120 lcdproc: Connection to LCDd process lost ()
Aug 6 04:28:55 php 25120 lcdproc: Connection to LCDd process lost ()
Aug 6 04:28:54 php 25120 lcdproc: Connection to LCDd process lost ()
Have a nice day,
fireodo

Hi,

there is another problem with LCDpros 0.12_1 (beside the increase processor activity since the update 12-13.05.24) when there is a Gateway latency problem or the WAN gets unexpectedly down,

Aug 6 04:28:48 rc.gateway_alarm 23648 >>> Gateway alarm: WAN_PPPOE (Addr:217.xxx.xxx.xxx Alarm:0 RTT:9.355ms RTTsd:.223ms Loss:5%)

LCDProc is flooding the log with this:

Aug 6 04:30:03 php 25120 lcdproc: Connection to LCDd process lost () Aug 6 04:28:55 php 25120 lcdproc: Connection to LCDd process lost () Aug 6 04:28:54 php 25120 lcdproc: Connection to LCDd process lost ()

Have a nice day,
fireodo

Might help someone, I had similar issues, but it turns out my pfsense didn't trust the self signed CA that signed the influxDB cert. Found out by stopping the service:

ps aux | grep tele kill -9 <PID>

And then running telegraf manually:

/usr/local/bin/telegraf -config=/usr/local/etc/telegraf.conf

Note that the service restart/stop buttons in the web gui did not work for me, only the start button (which shows up after I killed the process)

@allxi said in isc-bind package upgrade:

https://github.com/pfsense/FreeBSD-ports/commit/279801056eb46b74ce3828a77a7b679225817a2d#diff-a69ffe76fc45ab53d7931b2ee22b96681a82a9ef3245d8ea08eb0a217db0bb60

Thanks (sorry for the delayed response)

However its great we have this but this doesnt show when it will hit CE at all, as this commit was 2 years ago, but 9.16 is still in CE

While looking for something else I found that I also have similar messages in my syslog. Looking further I found this recommendation for the vnStat package:

"Every NIC is added on install. So if a NIC is added (or removed) on the firewall, remove the package and install again. If the firewall has data for a NIC vnStat will report the data even if the NIC has been removed.
A reinstall of the package will not change this as the firewall has data pertaining to the non existent data and thus other packages such as vnstat2 will report the data it has or has found."

Link: https://docs.netgate.com/pfsense/en/latest/packages/traffic-totals.html

Indeed I changed my hardware and restored the configuration from the old one. Some NICs changed from 1Gb to 10Gb.

However, after removing and installing the package I see this in the log:

Monitoring (10): tun_wg0 (1000 Mbit) pppoe1 (1000 Mbit) pfsync0 (1000 Mbit) pflog0 (1000 Mbit) ix1 (10000 Mbit) ix0 (10000 Mbit) igb1 (10 Mbit) igb0 (10 Mbit) enc0 (1000 Mbit) em0 (1000 Mbit)

And it's incorrect. My pppoe1 sits on ix0 and my fiber speed is 3/3Gbps, so higher than 1000Mbit vnStat thinks. Also igb0 and igb1 are 1000Mbit, not 10Mbit (they are not assigned yet, though).

I suppose the log messages we see are no more than a minor nuisance but is there a way to assign correct interface speeds for vnStat or disable these messages?

@Gertjan

Thank you! I Understand activities use resources, but if we have 50%+ cpu idle, probably not causing a problem? Or is that misleading?

I have the exact same hardware pfsense firmware/software all with the same speedtest gui in 3 different ISP/locations.

One location I have ATT Dedicated Fiber (new Install) that basically has zero network load but speed tests are all over the map (and large majority of tests are below the 90% minimums)

The other 2 locations have a lot of network traffic, have shared fiber and they are much more stable than the ATT dedicated fiber.

Since I have those three comparisons, I feel that proves the issue is with the ATT Dedicated fiber service. Yes or No / Agree disagree? Thanks!

@SteveITS said in pfSense Repository down?:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#packages-netgate-com-has-no-a-aaaa-record

Correct, no A or AAAA record.
This time SRV records ("server records ?") are looked for.

This is probably is, I'm just thinking out loud : everything is fine, but DNS isn't. pfSense can't call out for self. Seen that before, and I never understood how people to so. Default 'Netgate' DNS settings work, as I've shown above.

@dhenzler THANK YOU for posting this!!!!

I had been fighting this (and losing) for months now but, ran across this thread today and decided to try it out.
It WORKED!!!
At first I was more confused because I went to the system update and it showed the version 2.7.2 BUT, didn't give me an option to do the update from 2.7.0.
I ran the certctl rehash in the Diagnostics/Command Prompt box which then let me access the update.
And even before I ran the update I tested to see if the package manager would populate the list and, it did!
And it still works after doing the update! YAY!!!!

So again, thank you!

@beechclose FWIW, it turns out the limit isn't number of reflectors, but just the line length. There is a hard coded line length limit of 256 characters for the ini file. It is a known issue.

I put up a PR to increase this to 1024.

It is working like a dream outside of the status pages it is 100x faster with browser traffic on my secure system that I hunt for bugs with.