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.

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.

@bigjohns97 said in Ping monitoring:

Help me understand what the risks are here, to me this is nothing more than what an nmap scan would do.

Ntopng is an autonomous agent, whereas nmap is not. Consider that. You should look at the ntopng code and decide for your self. The best I can tell you is that I have, and I recommend against enabling it.

FWIW, you may have different views on network security that I do.

@fjmp24 said in Avahi : Windows not found my printer:

a rule IPv4 UDP VLAN_1 subnets * 224.0.0.251 5353 *
a rule IPv4 TCP/UDP VLAN_2 subnets * Printer * *
a rule IPv4 UDP VLAN_2 subnets * 224.0.0.251 5353 *

Posting rules like doesn't help much to be honest.. Have no clue to what could be above that making those moot..

Are those on the same interface even? You have 2 rules with vlan2 subnets as source, and another rule with vlan1 as source.. How would both networks be source into the same interface?

Seems you got it sorted so that is good, but next time you need help a picture of your rules showing the interface they are on, etc. is worth 10k words..