Messages

Even brand new devices can have hardware problems. :)

But if you were simply powering off without shutting down, then yes, that's probably the cause of the issue.  While ZFS is more resistant to that sort of thing, it's still not a good practice.

I know new devices can have hardware problems, I haven't had a new device with hardware problems in a long time and because so that and the unclean shutdowns made me think it was more likely a corrupted file system.

And yes I also know that's not a good practice to do an unclean shutdown, I had probably had my reason to do so when I did the unclean shutdowns and I was still figuring out some things about OPNsense since I am new to OPNsense. But I am not planning on anymore unclean shutdowns :)

OPNSense uses a date versioning system like Ubuntu and several other projects.  So it's not Major.Minor.Patch but instead Year.Month.Minor_Patch

Typically upgrading from one release to the other is pretty issue free, but occasionally there are releases which have bigger changes, such as the case with 23.7.

I was actually looking at the FreeBSD version it was based on and because it being based on FreeBSD and couldn't see why an upgrade could go badly wrong if they are still based on the same major FreeBSD version. Thanks for sharing that comparison, that makes more sense now of how the OPNsense versioning works.

You should do some hardware testing on your setup.  Run some SMART tests on your drives and see what they report.  Also, do a memtrst run or two.

Depending on the cause of the problem, it may return even if you're running ZFS.

This is a brand new device that I bought about 2 weeks ago. I was using UFS before and had turned the device off without powering it down correctly several times. I read in several places that UFS has more problems with this and that because ZFS has data integrity it makes it less likely to cause problems when that happens. Since I OPNsense installed with ZFS I haven't seen any weird output in dmesg and the syslog, so I suspect it was probably a corrupt UFS filesystem.

I'm new with OPNsense but not unfamiliar with operating systems, in general but to my knowledge updating from one minor version to the next should be without issues most of the time. Since OPNsense is based on FreeBSD I would expect the same, is that not the case with OPNsense most of the time?

How strange! It's weird that that would work. But I will bear that in mind and will give that a go on the next install. Sadly cannot try this now before work (night shift) as my wife is working from home today and I cannot break the internet, but will give this a go tomorrow!

The only logical explanation I can think of is that for some reason even though the physical port2 being connected to the ISP modem in bridge mode is actually seen as logical port1(igc0) in the os. I also tried manually going through option 2(Set interface IP address) and setting the LAN interface with a static ip and the WAN interface with dhcp but that didn't make dhcp give my wan interface a WAN ip either. I hope it works for you!

I don't know if it helps it sounds like your issue is similar to mine, as in your WAN interface not getting an ip from you ISP modem which is set in bridge mode. What was the case for me I had my LAN plugged in port1 and WAN plugged in port2 (which is the default)and then I didn't get a WAN IP from dhcp. What I ended up doing on making it work was change the interfaces assignment by using either ssh or a keyboard and a monitor to connect to OPNsense. Then I selected option 1, I then assigned igc0 as the WAN interface and igc1 as the LAN interface, after which my WAN interface was succesfully able to get an ip from dhcp. I don't know if it will work for you but I thought it would be worth mentioning for you to try.

Just to be clear I'm new to OPNsense myself but what I am missing from your network setup picture is the device which is running OPNsense, that will probably useful to know where the routing is done?

In my new installation I used ZFS as the filesystem instead of UFS which I was using before because the documentation seems to recommend it because it being more reliable than UFS.
https://docs.opnsense.org/manual/install.html

Install (UFS|ZFS) - Choose UFS or ZFS filesystem. ZFS is in most cases the best option as it is the most reliable option, but it does require enough capacity (a couple of gigabytes at least).

Everything is working again!

It seems my filesystem was corrupted, I tried running fsck but I seemed to have did it wrong. I also thought it might have been a hardware problem So I did a reinstall and restored my configuration now everything works again.

As a remind to myself I'm linking to previous forum posts about fsck, so that I can use that in case it happens again.
https://forum.opnsense.org/index.php?topic=22177.0
https://forum.opnsense.org/index.php?topic=22177.0

I decided to reboot my system to see if that would do anything, now Unbound won't start. When I login through the shell and try to start unbound I see the following message in the syslog.

opnsense 3173 - [meta sequenceId="62"] /usr/local/sbin/pluginctl: The command '/bin/kill -'TERM' '49004''(pid:/var/run/unbound.pid)  returned exit code '1', the output was 'kill: 49004: No such process'
[meta sequenceId="64"] /mnt: inode 18113529: check-hash failed
[meta sequenceId="65"] /mnt: inode 18113472: check-hash failed
[meta sequenceId="91"] g_vfs_done():gpt/rootfs[READ(offset=-8672233359260753920, length=32768)]error = 5
[meta sequenceId="92"] g_vfs_done():gpt/rootfs[READ(offset=-6168037127106658304, length=32768)]error = 5

It seems related to my filesystem, how do I fix it?

I will see if I can boot into single user mode or something and then try running a fsck.

I went to check on something in my Unbound report logging today but then I noticed it was empty, it was working af few days ago when I last checked. I tried disabling and then re-enabling the unbound report which didn't change anything and then finally I tried the reset option for Unbound data. Still the same problem and lastly I restarted the Unbound service but I don't think that would effect the reporting since dns resolving is still working.

https://ibb.co/LSN3JHN
https://ibb.co/CKHxGWY

Does anyone else have this or have an idea how to fix this?

Ik ben er achter gekomen wat het probleem is, ben wat documentatie tegen gekomen. Het blijkt dus dat als je een andere regex gebruikt het wel werkt. Heb dus nu dit geplaatst in de "Whitelist Domains"

Code Select Expand

.*bol\.com
Nu werkt het wel! Voor degene die het interesseert hier is de documentatie waar ik mijn antwoord gevonden heb.
https://github.com/opnsense/docs/blob/master/source/manual/unbound.rst
https://docs.opnsense.org/manual/unbound.html#blocklists

Ik ben sinds dit weekend over gestapt van een normale Asus router naar OPNSense als router en ben er erg blij mee, maar ik loop tegen wat aan. Ik gebruik de  "Blocklist functionaliteit van OPNSense en heb daar een aantal blocklist geselecteerd die worden toegepast. Nu probeerde ik via Tweakers bij een Productie naar de winkel door te klikken, in dit geval bol.com. Maar omdat al die links van bol.com het sub-domein tracking.bol.com gebruikt word werd dat geblokkeerd.

Nu dacht ik dan vul ik gewoon bol.com in on de de setting "Whitelist Domains" met een regex die ik van mijn Pihole heb over genomen en aangepast voor bol.com

Code Select Expand

(\.|^)bol\.com$
Vervolgens word het sub-domein tracking.bol.com alsnog geblokkeerd. Ik dacht misschien het kan zo zijn dat er wat gecacht is dus onder Unbound DNS -> General heb ik toen " Flush DNS Cache during reload" aangevinkt and Unbound herladen. Maar het sub-domain tracking.bol.com word nog steeds geblokkeerd. Dus mij vraag zie ik iets over het het hoofd of doe ik iets fout waar door dit niet werkt?