@jonathanlee said in Squid Proxy Server Clam AV showing outdated:

Where would I update if the packages show up to date?

You don't.
Half the planet sees this message nearly daily (using ANY OS, using the 'clamav' package).
Read the proposed :
DON'T PANIC! Read https://www.clamav.net/documents/upgrading-clamav
Which explains the message.

We tried to search for solution but unable to get it. Does anyone knows about the correct path for WAN interfaces.

@jimp amazing. Thank you.

@whitetiger-it said in FreeRadius Interfaces:

@nogbadthebad
Let's see if I understand correctly.
The switch, instead of querying the RADIUS on the firewall IP, queries a virtual (and therefore non-existent) IP that you have associated with the localhost of the firewall itself.

Nope its a virual address tied to the localhost interface, if I had bound my FreeRadius to the LAN interface IP and I had shut it down then devices couldn't authenticate.

Screenshot 2021-11-11 at 11.24.29.png

Good idea, but I didn't understand why.
The IP of the firewall is however known, for example because it is the Gateway of the network, there is DHCP, DNS, etc.

However, my question remains open.
Is the RADIUS interface the network on which the users are located or the one on which the servers/devices interrogated by the user are located?

From what you have posted, it seems to me that it is the second answer.

The radius interface is the IP address that Radius requests are sent to, as per "Enter the IP address (e.g. 192.168.100.1) of the listening interface. If you choose * then it means all interfaces. (Default: *)"

You can point your devices to any IP address any pfSense interface you want if you leave the IP address as the default of *

@rajid Followup:
I've also found that I need to add a filter to allow mdns packets to "pass", otherwise they end up blocked. I'm still not seeing any mdns responses using the avahi programs (such as "avahi-browse -a"), but "tcpdump" shows the packets are there on the wire.

@jimp thx for the hint it's working now, it totally make sense now. hope it will you @bbusa as well

Did you look in the suricata.log for the interface to see why Suricata was failing to start? You can view that log on the LOGS VIEW tab. The log is overwritten with each startup attempt of Suricata. It will contain the status of the last startup attempt of Suricata for the interface.

Was it complaining specifically about failure to allocate Stream Memcap memory? With lots of cores, that value must be increased substantially from the default. You can search on Google for info on configuring the value. I seem to recall running across a formula quite a long time ago that let you calculate how large that value needed to be for a given number of cores.

@4920441-0

If anyone is asking why this is a problem:

I try to configure three tunnels which should connect 4 OSPF routers with each other....

For the first tunnel I could allow 224.0.0.0/6 but what should I do with the other tunnels?

Thanks a lot..

Cheers

4920441

@tsmalmbe said in Snort Inline Mode caused WAN to drop every few minutes:

@bmeeks A minute to review this question of mine and comment? Highly appreciated as always.

The answer is very simple: switch to Legacy Mode if you want to use blocking with Snort (or Suricata) on your hardware.

I've said on this board innumerable times that Inline IPS Mode relies on the kernel netmap device, and the kernel netmap device relies on well-written support within the hardware NIC driver. If that support is not well-written (meaning bug free), then netmap does not work reliably. That in turn means Inline IPS Mode does not work reliably. "Not working reliably" can manifest in ways from simple disruption of traffic on the configured interface to potentially a complete lockup of the firewall. There is a warning dialog that is displayed at the top of the INTERFACE SETTINGS page when you switch an interface to Inline IPS Mode and save the change. The message clearly says you may experience difficulties.

You also have two installed packages that are likely not going to cooperate with the netmap kernel device: bandwidthd and softflowd. That's because when an interface is placed into netmap operation, it is disconnected from the kernel's control and placed under the the control of the app initiating the netmap connection. For the IPS/IDS packages, that would be Snort or Suricata.

@gertjan with OpenVPN I think I can handle it, but the problem with multiWAN as far as I know has not been fixed yet.

@icarson without more details of hardware and configuration i’m not sure it’s actionable or useful feedback.

@gertjan Well, this forum post indicates that it is possible to install packages while offline. I think 'pkg add' will do the trick after uploading the package to the pfSense system.

But thanks for clarifying for me about the fingerprints.

@gertjan I just wish they used more of the SSD for items, it is alot faster over a hard drive of the past. Use that SSD for items that are not part of non stop scanning. Remember upper and lower memory blocks back with MS-DOS 3.11 in the 90s with a 14mhz 8088 processor? It seems to me the resources that are available like that huge SSD are not being used as much as they could. I do understand the need for speed with the packet processing. However I can't stop wondering what could be put on that drive and not be constantly ready in NVRAM.

Hi a lot of times this is related to DNS problems. In my case on DNS Resolver > Network Interfaces it was missing pfBlockerNG DNSBL interface

Capture.PNG