@NogBadTheBad @Gertjan :
I received my spare SG-1100, set it up using the absolute basics and installed the FreeRADIUS package on that unit. Exact same issue.

So the problem was the FreeRADIUS Server Certificate which was not created automatically, like in Tom's video. Right after installing the package I got the following notice:
ce6fb673-565f-4701-99eb-2e839613f9dc-image.jpeg
This was exactly the same on my production SG-1100 unit.

I don't understand why the SC could not be created where the CA was created just fine. I found this other post right here on the forums of another SG-1100 user running into the same issue. Could this be related to the SG-1100 specifically?

Anyway I created a Server Certificate under de FreeRADIUS CA and boom the server is running and it is authenticating.

Just one question as this is the first time I create my own certificate: The common name field cannot be left blank or I'll get an error creating the certificate:
4a3ac69e-ad16-4081-838b-ffc96bf1bfa5-image.jpeg

However I didn't know what to enter there for this special FreeRADIUS use case. So I just entered a non-existing url. Will that be adequate?

Thanks for your help!

Pete

@zoltrix
It seems you are correct, if I load nut on a workstation, I can poll statistics if I know the configured name and address without any configuration on the client side. You could make this harder by choosing a unique name instead of the default 'ups'. I don't see this as a security risk, but the nut manual has a section 'Notes on securing NUT' which may be of use. An easy fix on pfsense would be to block LAN access to the NUT port for all but trusted workstations.

@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.

@ciscox That's a side effect of the screenshot. The interfaces LAN and IOT are indeed selected and I see mDNS traffic on the IOT interface and TCP traffic between the iOS device and the TV. If I deactivate the Avahi service the iOS device cannot detect the TV as AirPlay target. Re-activating the service makes the TV detectable again.

Unfortunately my packet capture did not reveal anything useful. The mDNS TTLs are 255 and the minimum TTL of the TCP traffic between the iOS device and the TV is 63. Other than a single ICMP destination port 59536 unreachable message (which makes sense as traffic originating from the IOT subnet to the LAN subnet is blocked) I don't see anything pointing to the issue causing the failing connection 🤔

When the iOS device is in the same subnet as the TV the AirPlay screen cast works as expected of course (without Avahi).

@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.

@jdeloach very true.. Yeah that won't be there if you don't have arpwatch installed..

@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

@nazuro said in MDNS struggles:

@bmeeks Thank you so much - that seems to have solved the issue! And thanks to John as well

Glad that helped you.

What really happens is when Suricata stops and then restarts, it makes a call to the netmap device code to first "close" the open netmap interface (when stopping); and then it makes a call to "open" the netmap interface (when starting). The netmap kernel device performs a literal "down" and then "up" cycle as it switches the interface from and to netmap-mode (netmap-mode unhooks the interface from its normal kernel connections). You can see this in your log snippet:

Oct 13 00:30:47 pfSense kernel: igb1: link state changed to DOWN Oct 13 00:30:47 pfSense kernel: igb1.11: link state changed to DOWN Oct 13 00:30:47 pfSense kernel: igb1.12: link state changed to DOWN Oct 13 00:30:47 pfSense kernel: igb1.14: link state changed to DOWN

followed later by:

Oct 13 00:30:49 pfSense kernel: igb1: link state changed to UP Oct 13 00:30:49 pfSense kernel: igb1.11: link state changed to UP Oct 13 00:30:49 pfSense kernel: igb1.12: link state changed to UP Oct 13 00:30:49 pfSense kernel: igb1.14: link state changed to UP

Using the "Live Update" mode for rules updates means Suricata never actually stops and restarts. It keeps running during the update cycle and does the in-memory rules duplication/update thing I described earlier. Since it never restarts, it does not call the netmap code to close and then open the interface.

@wifi-will Thank you.... that did help me....

@gertjan
Thank you for pointing that setting out. I added a "1" in front to make it a million and a half. No more alerts.

@gertjan at work now but will check later tonight.

@ecnerwal como voltar a versão do squid?

@valerica said in How to block facebook.com in pfSense?:

Host: facebook
Parent domain of host: facebook.com
Return IP address: 127.0.0.1

This means :
facebook.facebook.com will return 127.0.0.1.

Did you check that ? (nslookup, dig etc)
Do you want that ?

thanks for the feedback. I'll try both.

@cubeyglyph For what it is worth I realized my error. I configured the listen port on the firewall the same for both peers, I did not realize that each peer needed a unique port to listen on, I thought it would still route properly. Once I changed the peer listen port to tow unique values both peers came up just fine.

If you have a Netgate appliance (SG-1100, SG-3100, etc.), try a power off restart. The crypto hardware in certain Netgate appliances can wind up in an indeterminate state after an upgrade. This leads to crypto failures (so problems with decrypting/encrypting things for authentication and such). A simple restart does not fix the problem. You must do a power off/power on sequence to reset the crypto chip.

So try going to the DIAGNOSTICS menu in pfSense and choose HALT. When the system fully stops (or shutdowns on its own), then you can remove the power plug for a few seconds, reinsert it, and power up the box. See if that helps.

WARNING! Make sure your box has actually gone into halt mode before pulling the power!

@grillp

The UDP relay package is only one part of this puzzle. It helps the secure LAN side "discover" your Bonjour/Chromecast/mDNS/Sonos/SSDP/etc devices.

But in addition to that, you are going to have to punch some holes into your firewall so that those devices can communicate with stuff that's on your secure LAN.

This post helped me with Sonos stuff but can also be used as a basis for anything else.: https://www.reddit.com/r/Ubiquiti/comments/gu19sa/iot_vlan_settings_specific_to_sonos/

Here's what the end result looks like in the firewall rules on my IoT interface
son is an alias containing the IPs of Sonos hosts
Sonos_TCP0, Sonos_UDP0, Sonos_TCP1, and Sonos_UDP1 are aliases for the ports needed, as outlined in the Reddit thread specific to Sonos. These might not apply to your situation. But remember, your IoT devices might require being allowed to initiate some traffic to your LAN devices. Unless you open up the ports required, things might not work right.

60a861cb-7295-480c-8883-c951772c5dba-image.png

@flashpan You shouldn't need to actually get it to power down, you just want to make sure that it reacts to the events from the UPS. So unplug for 15-20 secs then plug back in should be enough to see if it gets "lost power and power returned". Then just tweak the apcupsd config on pfsense for probably "min time left" or "min battery charge" for the shutdown. Just keep in mind that the Windows server is actually controlling the UPS and you have it configured to "shutdown systems and UPS after being on battery for 10 minutes", so you'll need to figure out how to tell apcupsd on pfSense "shutdown after being on battery for 5 minutes".
Nice to see that at least you are able to get status. That is 90% of it.