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

@SteveITS

Thank you for the clarification. You're right — better to be safe. I’ll update FW2 when I'm on site, and then FW1, which is my usual one.

Thanks everyone. That did it. No more errors!!

Try installing it at the CLI with debug to get more error output:
pkg -d install pfSense-pkg-squid

@AWeidner its just pfsense trying to proect you against a rebind. When you foward to something that is normal some external public NS - which normally should not be returning rfc1918.

You might want to read some of the history of rebind attacks. And why this good protection to have in place.

@elvisimprsntr thanks for your suggestion. I will give it a try.

Nice. Weird though. 😕

@NickJH
Not clear, what you intend to achieve with this, but the Directory container in Apache is meant to be used for local paths. "/" might not be correct here.

If you need to describe a virtual path use "Location".

There was a backend issue that's now fixed.

@Gertjan said in Does not have a public address and is behind NAT:

Managed to solve the problem.

You need to enter any fictitious name and your external IP in DNS Resolver. I entered both my pfsense on one and the second pfsense.Снимок экрана 2025-07-21 в 15.38.01.png In phase 1 you need to register.
Снимок экрана 2025-07-21 в 15.39.32.png
After which everything started working.

Hi @SteveITS.

That was an excellent tip, I had missed the "self" target completely. This allowed me to get rid of all of my firewall aliases I needed earlier.

Thanks!

Yup, there was a backend issue. Should be good now.

Mmm that^.

However what you will see is that after booting back into the 24.11 BE the update branch will still be set to 25.07-RC because that was the last thing that was done before the upgrade took the snapshot. So if you plan to run 24.11 for some time after reverting you would need to set the update branch back to 24.11 in that BE before doing any package operations.

Hmm, but they are policy based tunnels? And 300 Phase 1 configs not a total of 300 Phase 2 configs for example?

I'm not aware of any issue in 2.8 that might present like that for IPSec.

Currently nothing I'm aware of but going forward some functions will likely be written in go and hence in the Nexus package. Obviously that assumes the Nexus package is always present so it is automatically re-installed at upgrade.

Recently done four of them. Two upgrades from 2.7.2 and two net installed. All went ok & reinstalled packages after.

I agree an iso would be useful but I’ve managed without.

Next one will be an ESXI vm, so will try both methods on that.

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

Merged I could not test it but it is in there with the make file now and the distinfo file

@stephenw10

Let me know if you can test that out

Dont use this I am having issues with the MASTER SITES and patches folder it wont make clean install all the way

@cybrnook

It looks if you are referring to the pimd engine version

854cb5be-fd74-43b0-848a-b83df5637c1b-image.png

Which is quite old, and as far as I know not working under FreeBSD. I have compiled the never released pimd-3.0.b1 version (using FreeBSD15 current).

@Euroguy said in Router advertisement not sending default gateway:

So, followup after a reinstallation of the system

Short answer is, things now seem to work.

Glad to see you got it up and running :)

I get both DHCP4 and 6 clients with leases now (although status of lease seems broken, always showing black down arrow even though lease is active and remote machine is up and active

I see that from time to time too. I think there are some timers that you can tweak (can't recall which ones though) that determines how long it takes without a "sign of life" before the client is marked as offline. For IPv4 there's an ARP timer ... and for v6 it should be an equivalent NDP timer. Can be set in System / Advanced / Tunables once you find out what they are called :)

DHCP6 server fails as DHCP requests / Discovery is done on fe80::/10 and that is not considered to be LAN it seems. I had to add a LAN allow rule for fe80::10 to ff02::/16 like this for DHCP6 to work:
e98b2093-2534-4c7e-9c09-6d54251d537d-image.png

That rule shouldn't be needed, it is part of the automatic rule set added by pfSense. I get those by means of pfSense magic: (check in /tmp/rules.debug)

pass in quick on $WAN proto udp from fe80::/10 port = 546 to fe80::/10 port = 546 ridentifier 1000000463 label "allow dhcpv6 client in WAN" pass quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 ridentifier 1000002551 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 ridentifier 1000002552 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 ridentifier 1000002553 label "allow access to DHCPv6 server" pass quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 ridentifier 1000002554 label "allow access to DHCPv6 server" <snip>

Update:
the timer tweak I used a long time ago was

net.link.ether.inet.max_age=60

which make the cached ARP-entry lifetime 60 seconds, I wanted clients to go offline faster. Default is 1200s. See https://man.freebsd.org/cgi/man.cgi?query=arp&sektion=4

24319ba3-b5d5-4add-b251-9993249ff5a6-image.png

@stephenw10 i have same issue