Messages

+1 for run memtest86+ first.

That particular UDIMM module from @patient0 is a Low-profile one with Samsung(SEC) chips, virtually any Low-profile DDR4-2666(PC4-21300) or faster should work with most hardware, the memory speed/latency is adjusted by the BIOS based on the SPD.

If the system is configured with single module, any decent brand should work, but if it is configured in dual-channel 2x4G, then they should be analyzed individually to check what module is failing(if that's the case) then replace the failed module with the same brand/model, or a brand-new matched kit.

I've also updated from 25.7.8 to 25.7.9 today trough the Dashboard [System:Firmware] and everything went fine, though never experienced this Dashboard hiccups(I use Firefox) but wondering why some users are reporting this issue after updates.

However I've experienced this problems in the past with some Rpi/ARM distributions running from bare slow USB/SDCard media, but that's expected unless the system is loaded/running from RAM disk, and/or when testing on older hardware with limited resources.

Regards

Hi, this was also posted here as well, I've been monitoring my firewall since however all seems to be working fine so far.

Regards

Hello, I will post here a similar update issue just for reference.

This past Nov. 26 I did performed an routine update from 25.7.7_4 through the dashboard and a Danger popup appeared during pkg files extraction/upgrade, the Danger popup disappeared itself after and I let the update to complete till system reboot.
You cannot view this attachment.

Regardless of this Danger error popup, the system seems to success the operation, unfortunately I did not find anything useful related to the error and `dmesg` was clean after reboot.
You cannot view this attachment.
You cannot view this attachment.
The Dashboard the [System:Firmware] page and the console all shows that the system upgrade have success regardless.

PS My system is a VM on ZFS so I always perform updates/upgrades under new ZFS/BE's, so trying to reproduce this can easy though haven't done that.
Also I perform min-version updates through the dashboard while major-version upgrades from the console to minimize errors but that's just me.

Regards

[*]

Hello, I will post my rather clunky TFB setup and my own answer, in case someone is asking for a similar config on a Transparent Filtering Bridge with slightly different config from the How-To's, just for the non-networking guys like me, IPv6 is completely disabled in this example*.

This requires for 3 interfaces as expected, in my case two physical IF(passthrough) for the [TFB] and one virtual admin IF(vtnet0, virtio).

Scenario, you follow the How-To to setup an TFB, but added an 3rd interface to administer OPNsense, now Updates and/or Plugins downloads does not work because you've set the Transparent Filtering Bridge related interfaces to NONE as recommended in the How-To:

Set Interfaces [WAN] + [LAN] + [BRIDGE] to:
  IPv4 Configuration Type: NONE
  IPv6 Configuration Type: NONE*

However since we added a 3rd interface for admin, all we have to do is to set the Gateway for it under [System: Gateways: Configuration], my admin interface is called [ADM]:
You cannot view this attachment.

Now under [System: Settings: General] I've set the preferred DNS to use that Gateway (192.168.0.1):
You cannot view this attachment.

After reboot OPNsense is now able to update and install plugins again thru the admin interface while leaving its pure Transparent Filtering Bridge operation intact:
You cannot view this attachment.

However in my case this was a bit different as the OPNsense is a VM guest and the admin virtual interface(vtnet0) is connected to the host(Bhyve) on the public switch, so the admin interface internet-connection will be thru the hypervisor which in contrast loops back to the TFB access-point.

Regards

[Boot Environments]

Hello all,

My client runs an OPNsense firewall on VMware. It runs really well and takes no real resources. I am building a replacement 25.7 firewall. As I got to the storage config I stopped thinking...should I allocate two disks and run these in a ZFS raid 1 pair. Well can someone comment if this makes any sense under VMware?

Thanks,
Steve

Hi spetrillo, I could not speak for VMWare Hypervisor or cloud based but I'm using OPNsense under FreeBSD Bhyve with underlying ZFS, I've just installed OPNsense on a single RAW image(can also be a ZVOL) formatted as single/stripe ZFS disk from the OPN installer.

With ZFS even on a single disk the system will take advantages of the ZFS compression/snapshots/Boot Environments etc, despite it being on a single disk the ZFS filesystem is resilient/superior to any other filesystem and bulletproof wen installed on two or more drives, but as mentioned completely unnecessary to be installed on two vdisks on the top level unless for testing/development purposes.

And speaking on "Boot Environments" this is a must have feature especially if you upgrade often, with a ZFS installation the OPNsense UI will enable a feature called "System:Snapshots" and this will benefit the average users with little to no command-line experience to easily revert back to a previous working OPNsense state, or to create a new Boot Environment and reboot into it to experiment with system wide changes, here is a screenshot of such feature:
You cannot view this attachment.
Also with ZFS there are additional advantages such as scheduled system snapshots, export/import but not the case here, between I've been using OPNsense with ZFS way before it was experimentally introduced and later officially added to the installer and I can tell you it is rock solid/stable on any modern hardware and/or VM with decent resources.

Also I've been doing something similar on another system with Qemu/KVM for quite some time but with BTRFS on the host data store for development/testing with no issues at all.

Regards

[NONE]

Apologies for asking such dumb questions, seems there's not many users with transparent filtering bridges with alternate configurations, nor around the web except for few YT videos just telling how to install it.

Between I've just set on all interfaces the IPv4/IPv6 Configuration Type to: NONE except for the [ADM](admin) interface.

One of the reasons for asking was because my ISP strikes it again and broke the IPv6 and OPNsense was unable to be upgraded unless IPv4 was set to DHCP in the [WAN] interface:
You cannot view this attachment.

I will try update/upgrade OPNsense host thru the admin interface, otherwise maybe I should stop being a bit too paranoid and leave the IPv4 set to DHCP on the [WAN] interface and add some rules there even if this is disregarded by the recommended setup from the docs.

Regards

What are your specific questions? Just go ahead and ask them ;-)

You have read the documentation on transparent filtering bridge?

Hi Patrick, I've pushed wrong buttons while writing, but posted them already.

Regards

Hello, I'm really sorry if this was asked previously but I have some specific question regarding a typical Transparent Filtering Bridge configuration.

I was using OPNsense for several years without any issues so far, however I've recently switched from a standard setup to the Transparent Filtering Bridge mode because switched from DSL to an CGNAT/ISP, so I have some questions in regards some setting which typically differs from the OPNsense TFB how-to documentation

This is my current TFB setup(IPv6 is disabled):

Code Select Expand

Interfaces: [WAN] -> igb0
  IPv4 Configuration Type: DHCP (It was: NONE)
  IPv6 Configuration Type: NONE (It was: DHCPv6)

Interfaces: [LAN] -> igb1
  IPv4 Configuration Type: NONE
  IPv6 Configuration Type: NONE (It was: Track Interface)

Interfaces: [TFB] -> igb0 + igb1
  IPv4 Configuration Type: NONE
  IPv6 Configuration Type: NONE

Interfaces: [ADM] -> vtnet0
  IPv4 Configuration Type: Static IPv4
  IPv6 Configuration Type: NONE

My question is if the above TFB configuration looks acceptable since I had set the IPv4 to DHCP on the [WAN] interface, otherwise OPNsense is unable to be upgrade as expected since there's no route to host.

OPNsense and zenarmor how-to's both specify to set the IPv4's to NONE but in my case I had to set it, the TFB rules seems to work as intended however is there any security implication leaving the [WAN] IPv4 set to DHCP alway plus the required rule to "Allow All" in such IF?

I could disable and set it back to NONE after OPNsense upgrades and reboot but that is a bit of a hassle.

PS the [ADM] interface is only for local administration, also sorry as I've push Post instead Preview while writing.

Regards

Nice, thank you. May consider picking this up in core in the future if boot code incompatibilities are to become more common.


Cheers,
Franco

Hi Franco, I've edited the previous post and added the output for "gpz/zfsboot" code update as well for reference.

Regards

[Sample output from my FreeBSD host:]

Hello, I've updated the `bootcode-update` utility to support GPT labels for compatibility with later FreeBSD releases in case someone wants to play with on a VM.

Sample output from my FreeBSD host:

Code Select Expand

root@nas-mserver: ~# bootcode-update -v
bootcode-update 0.3.6
root@nas-mserver: ~# bootcode-update -e

UEFI Partition: [ ada0p1 ]
Disk Serial:    [ TNS519GYXXXXXX ]
Proceed with EFI bootcode update for the following geom: [ada0p1] (Y/n)?: y
Proceeding...
=> Updating EFI bootcode on ada0p1
/boot/loader.efi -> /boot/efi/efi/boot/bootx64.efi
/boot/loader.efi -> /boot/efi/efi/freebsd/loader.efi
=> Success!


UEFI Partition: [ ada1p1 ]
Disk Serial:    [ 140817TM85A3TDXXXXXX ]
Proceed with EFI bootcode update for the following geom: [ada1p1] (Y/n)?: y
Proceeding...
=> Updating EFI bootcode on ada1p1
/boot/loader.efi -> /tmp/boot_esp/efi/boot/bootx64.efi
/boot/loader.efi -> /tmp/boot_esp/efi/freebsd/loader.efi
=> Success!


Sample output from my OPNsense VM:

Code Select Expand

root@fw-opnsense:~ # uname -a
FreeBSD fw-opnsense.arpa 14.3-RELEASE-p2 FreeBSD 14.3-RELEASE-p2 stable/25.7-n271676-ab2281de1853 SMP amd64
root@fw-opnsense:~ # bootcode-update -v
bootcode-update 0.3.6
root@fw-opnsense:~ # bootcode-update -e

UEFI Partition: [ vtbd0p1 ]
Disk Serial:    [ BHYVE-125E-B3XX-XXXX ]
Proceed with EFI bootcode update for the following geom: [vtbd0p1] (Y/n)?: y
Proceeding...
=> Updating EFI bootcode on vtbd0p1
/boot/loader.efi -> /boot/efi/efi/boot/bootx64.efi
/boot/loader.efi -> /boot/efi/efi/freebsd/loader.efi
=> Success!

Sample output updating GPT/ZFSBOOT:

Code Select Expand

root@nas-mserver: ~# bootcode-update -g

Boot Partition: [ ada0p2 ]
Disk Serial:    [ TNS519GYXXXXXX ]
Pool Member:    [ zroot: '/dev/ada0p4' ]
Proceed with GPT/ZFS bootcode update for the following geom: [ada0p2] (Y/n)?: y
Proceeding...
=> Updating GPT/ZFS bootcode on ada0p2
partcode written to ada0p2
bootcode written to ada0
=> Success!


Boot Partition: [ ada1p2 ]
Disk Serial:    [ 140817TM85A3TDXXXXXX ]
Pool Member:    [ zroot: '/dev/ada1p4' ]
Proceed with GPT/ZFS bootcode update for the following geom: [ada1p2] (Y/n)?: y
Proceeding...
=> Updating GPT/ZFS bootcode on ada1p2
partcode written to ada1p2
bootcode written to ada1
=> Success!

Regards

This is one of the reasons I've created an `bootcode-update` utility to update my FreeBSD hosts boot mirrors whenever I upgrade zroot zpool, or the GPT/EFI bootcode gets updated from freebsd-update, also it works on RAIDZx when I've tested some time ago.

The `bootcode-update` utility can be found HERE so you can see how it works and make your own script for update automation.

Be aware that this utility is an experimental attempt for it and I haven't updated that in a while, though I still use it at my own risk on my FreeBSD host and OPNsense, though it does not support yet with the new FreeBSD EFI gpt/label layout just gpt/id, thinking to update it though.

Also be aware that updating bootcode either GPT/EFI/ZFS may prevent you from boot very old Boot Environments as expected, in such case the user need to manually mount said BE's and update the new bootcode files manually or rollback them on disks, though if the zroot zpool was upgraded this may also prevent old BE's from booting.

So always make sure you want to really update them.

Regards

[System: Gateways: Configuration]

Hello, I'm not sure about your OPNsense setup but you can go to [System: Gateways: Configuration] to add/edit GWs then edit the Dashboard widget and add additional gateways:

You cannot view this attachment.

I run a Transparent Filtering Bridge and has no DHCP servers active as expected, so I really don't need it but I've just added IP4 GW for monitor/informational purposes whether it is up or down.

Regards

With a mirror, a three-way mirror almost makes more sense than a hot spare. Hot spares are more useful for RAIDZ/RAIDZ2.

+1 on this.

Also with a single ZFS disk, one can export the latest Boot Environment to a safe place, and can be later imported in case of disk failure and your back to a working order in minutes, and now with the Dashboard Snapshots one can easily update/upgrade with peace of mind ;)

You cannot view this attachment.

👉 Been using OPNsense since v 16.x with Root On ZFS way before the initial ZFS installer script was made and I can tell its pretty solid stable.

Regards

From the first validation screenshots you can see there is an extra whitespace at the end "3478 ", maybe that's a CR (\r) from Windows line endings or a spurious LF (\n) altogether being converted into a space, but that is strange input like

3478
,4379

What are you actually pasting? Just paste it here in the forum...


Cheers,
Franco

Hi @franco, I did noticed that little spaces as well, also Patrick mentioned it too and I though it was just the GUI output.
However as you said it was provably from copying stuff from random websites in a hurry searching for Steam and some game ports to play behind the TFB.

I'm really sorry for all the noise and this can be marked as solved, so next time I will check/format on my text editor before copying a bunch of ports from the web when creating aliases, also when entering hosts IP's manually it requires for comma at the end of each IP too.

Regards