Messages

Figured it out.

After the update when it reboots hit <ESC> at the boot screen then enter
# set hint.uart.0.disabled=1
# set hint.uart.1.disabled=1
# boot

After it boots login and edit /boot/device.hints and change it like so then reboot to test the changes:

hint.atkbdc.0.at="isa"
hint.atkbdc.0.port="0x060"
hint.atkbd.0.at="atkbdc"
hint.atkbd.0.irq="1"
hint.psm.0.at="atkbdc"
hint.psm.0.irq="12"
hint.sc.0.at="isa"
hint.sc.0.flags="0x100"
#hint.uart.0.at="isa"
#hint.uart.0.port="0x3F8"
#hint.uart.0.flags="0x10"
#hint.uart.0.irq="4"
#hint.uart.1.at="isa"
#hint.uart.1.port="0x2F8"
#hint.uart.1.irq="3"
hint.atrtc.0.at="isa"
hint.atrtc.0.port="0x70"
hint.atrtc.0.irq="8"
hint.attimer.0.at="isa"
hint.attimer.0.port="0x40"
hint.attimer.0.irq="0"
hint.acpi_throttle.0.disabled="1"
hint.p4tcc.0.disabled="1"
hint.uart.0.disabled="1"
hint.uart.1.disabled="1"

This worked for me and I learned a lot on this adventure!

8  )

I'm leaning towards this: After some back and forth today we are rolling back a console default change done in FreeBSD 14.2 that we do not think is necessary at this particular point in time.

In FreeBSD 14.2, the default console behavior is primarily driven by the vt(4) driver, which is now the recommended console driver, replacing the older syscons(4).

It seems specific to the particular system it was working on.

If I lock the base package and update it boots so it is something in the base package that has changed.

Using verbose boot it errors and stops at trying to initializing the uart on the motherboard, no actual serial port on the board but a uart header. I haven't tried attaching a serial adapter to the uart yet since I don't remember where I put them.

Right now I'm reading up on how to clone the repo and build the project to then try and find the base package and look through the code.

Thanks 8  )

On a system that has been running just fine with 24.7 and 25.1 prior to the latest update.

I applied the latest updates and it throws an error when booting now:

CPU0:<ACPI CPU> on acpi0

The system uses DDR5 so it's relatively new hardware.

I reinstalled 25.1 and applied the update with the same result.

Also tried installing the latest FreeBSD on this system and applied updates and it boots fine.

Any hint at how I could track this issue down?

I'm going to try installing 25.1 and apply the updates on a different system and see what happens.

8  )

I also have never seen any alerts no matter how I configure the system, Suricata alone on a test install or with other plugins.

Does anyone using IDS/IPS actually have it working properly showing alerts? Does anyone actually use IDS/IPS on OPNsense?

I wound up installing an IPFire system on the edge before the OPNsense system and Suricata is working just fine on that system.

I've experienced the same problem. Switching to Hyperscan makes the process no longer crash, but detection's don't occur. Does anything get detected once you've switched to Hyperscan?

I'm seeing the same error message on different systems both OPNsense and other platforms. So I don't think it's specific to OPNsense.

The small appliance I have OPNsense installed on has 16Gb ram and also runs Zenarmor with Elasticsearch v8, CrowdSec and Ntopng with Redis using Database Count of 16.

I've never been able to get Intrusion Prevention working with this particular configuration so I moved Suricata to an Edge Firewall running IPFire and the ram usage stays below 4Gb. When I tried OPNsense in a VM with 32Gb and Only Suricata it never showed any alerts so I shelved it to research what's going on under the hood when I have time.

YMMV

What protocols, ports and ip addresses do I need to allow on an upstream edge firewall that blocks all outbound traffic unless a specific rule allows it?

So far I've identified UDP 5355 and ICMP to any of these IP addresses:

104.155.129.221
104.198.6.78
34.74.12.235
35.198.172.108
34.65.117.157
34.92.15.156
35.244.50.89
35.189.37.160

Re-re-re-re-install went smooth, everything is back up working the way it should be except this time I haven't installed Zenarmor yet, going to give it a couple weeks and then try.  ;) ;)

I took a look at the php code, undid the rules and now I'm locked out of the webgui  ;D

Also see a lot of this: configd.py   action rfc2136.reload.lan not found for user root

Going to re-install (fourth time) and start with the web proxy first.


If this was a client I'd be recommending a different solution...  8)

Greetings,

I was following Zenarmor instructions to setup proxy. https://www.zenarmor.com/docs/network-security-tutorials/how-to-set-up-caching-proxy-in-opnsense#3-enable-transparent-http-and-ssl-mode and I noticed "Add a new firewall rule".

Well, that didn't go so well, 80/443 access blocked now. I tried to remove those two rules and that hosed the system.

I've put the system aside until I can look at it in depth so it's not a priority. What I was wondering is if anyone else tried those links to add rules and have them work?

Thanks.

Thanks for the pointer.

I wound up adding a localhost ip, dns overide and the dns overide fqdn to alternate hostnames.

I might add another nic and dedicate that to managing systems.

New to OPNsense here.

Is there a howto on configuring web GUI access on only LAN segment? Following any of the search results and docs do not work as expected.

On the actual OPNsense system using the diagnostics DNS lookup I get the LAN IP only which is what I want to see returned on any system on the LAN segment. (Do not register system A/AAAA records checked)

Issuing "dig <opnsense fqdn>" on any system on the LAN segment returns all Internal IPs?


For now I've brute forced it in the hosts file on all the systems, there has to be a better way.

Any pointers?

Thanks!