Messages

All there is is the log of the restarted procedure, after I made room in /var/log. The initial run stopped when trying to install suricata while /var/log/ was 100% full. But here it is anyway.

No, unfortunately not. When something fails I'm totally focussed on restoring functionality. I'll try to do better next time. Maybe it'll help to keep a history of logs of opnsense-update?

While updating from 25.10.1_2 to the latest release the update process stopped while updating suricata with "/var/log/suricata: filesystem full", or something along this line. Sorry, I forgot again to save the update log file. Anyway, as it turns out, the directory /var/log/suricata didn't even exist. But /var/log/resolver was eating up over 90% of the file system space, leaving no free space. So, I deleted all the crap, restarted the update and everything looks alright now.

I would like to kindly ask that the update procedure gets augmented with sanity checks to prevent out of memory conditions and possibly more stuff. You guys probably have a lot more ideas than me.

The more important bit to me however, is that unbound can fill up the entire /var/log filesystem because there doesn't seem to be proper log file rotation. For now I have deactivated query logging to gain some time before consuming all available disk space again.

And there's one more thing: While investigating I saw that the /var/log filesystem is mounted twice:

Code Select Expand

root@firewall:~ # df -h
Filesystem                  Size    Used  Avail Capacity  Mounted on
zroot/ROOT/default          221G    1.6G    219G    1%    /
devfs                        1.0K      0B    1.0K    0%    /dev
/dev/gpt/efifs              256M    864K    255M    0%    /boot/efi
zroot                        219G    96K    219G    0%    /zroot
zroot/tmp                    219G    96K    219G    0%    /tmp
zroot/var/audit              219G    96K    219G    0%    /var/audit
zroot/usr/home              219G    96K    219G    0%    /usr/home
zroot/var/log                220G    311M    219G    0%    /var/log
zroot/var/crash              219G    96K    219G    0%    /var/crash
zroot/var/tmp                219G    96K    219G    0%    /var/tmp
zroot/usr/src                219G    96K    219G    0%    /usr/src
zroot/var/mail              219G    136K    219G    0%    /var/mail
zroot/usr/ports              219G    96K    219G    0%    /usr/ports
tmpfs                        2.0G    2.6M    2.0G    0%    /var/log
tmpfs                        1.2G    3.0M    1.2G    0%    /tmp
tmpfs                        1.2G    152K    1.2G    0%    /var/lib/php/tmp
devfs                        1.0K      0B    1.0K    0%    /var/dhcpd/dev
devfs                        1.0K      0B    1.0K    0%    /var/unbound/dev
/usr/local/lib/python3.11    221G    1.6G    219G    1%    /var/unbound/usr/local/lib/python3.11
/lib                        221G    1.6G    219G    1%    /var/unbound/lib
root@firewall:~ #
I know what it means and I know that it works fine, but why is /var/log not unmounted before mounting tmpfs in its place?

On a side note, I had lots of TLS Handshake timeouts with fontawsome.com in the last 2 days (Firefox 140). Luckily, they can be blocked without defects to the site using noscript ...

Thanks guys, your discussion adds valuable information that helped me get my setup running (finally). But while experimenting with the settings I noticed something:

At a site with limited upload capacity, traffic from one network needs to be de-prioritised when other traffic is present. So, I added an upload pipe with the full nominal bandwidth to the ISP, added two weighted queues and the rules (great to have interface pairs in rules!). Generally, everything works as expected. Occasionally however, I get DNS resolution failures on the hi-prio networks while the low-prio network is uploading at full speed. This has not been observed before using traffic shaping. I'm not 100% sure what is going on. Shifting queue weights doesn't seem to do much to solve the issue. Latest test is to lower the pipe bandwidth to a few Mbits below the nominal bandwidth because the connection is via VDSL and the actual bandwidth is fluctuating somewhat. I'm guessing that physical bandwidth below pipe bandwidth may mess with the scheduling.

Since the DNS timeouts occur only sporadically, I can't be sure if this really fixes the issue. Has anyone else seen this and is there a know solution?

If the ISP's Combo router provides a way for the customer to add routes, you don't have to do double NAT. Define the networks your OPNsense should handle, add the OPNsense as router for these networks to the Combo router's routing table. Then, add the necessary firewall rules to the WAN of your OPNsense and turn off NAT on it. Now, only the ISP router does NAT.

IPv6 doesn't need NAT. Just make sure the ISP router can delegate a prefix to OPNsense.

Ok, I see. It's a community plugin after all. Thanks for the info and please keep the porting effort up.

B.t.w. Is there a way to switch the repository for this plugin?

I'm currently experimenting with the NDP proxy go and I have to say that this is an invaluable tool if you want to use an existing segmented network behind a LTE/5G router because carriers only hand out /64 prefixes. That said, I would love to use the automatic aliases as documented in the OPNsense Help, but I can't find the settings in the UI. Is this a problem with my OPNsense 25.10.1_2-amd64 + os-ndp-proxy-go 1.0 (says 0.1 in the changelog) installation or is a problem with the OPNsense docs? After all, the ndp-proxy website doesn't mention aliases.

@mooh These firewall rules have nothing to do with the default route in the routing table.

I agree, it doesn't change the kernel routing. Thanks to your response I now understand the question better, so please ignore my comment.

Have you looked into the Firewall:Settings:Advanced:"Disable force gateway" setting? By default OPNsense creates a default policy route for traffic originating from the FW itself.

Same happening for me updating one of my DEC750s from 25.10_2. on the first one, the process went exactly as described, updating pkg first, then another check followed by an update to 25.10.1.

The other however, did not update pkg, produced the ,,danger" message, stopped screen updates around package 21 of 75 and the stopped responding altogether, 403 errors via https, immediate logout via ssh and on the console with the ,,sh: /usr/local/libexec/opnsense-auth: not found".

Speaking of the console, the output didn't look anything like OPNsense booting. Luckily, I created a snapshot before the first attempt at updating and so I was able to restore the system from that.

Back logged in via https, I noticed that pkg is already at 2.3.1_1. This is different from the other system and I have no explanation for that but shouldn't pose a problem as that is what the first stage of upgrading should yield anyway. So I started the update again. Again, the danger message popped up but the update procedure continued to the end and the reboot was successful. However, my maintenance window was up, so I didn't dig into the cause of the error message and instead booted the know-good snapshot.

That's the story as it happened Thursday evening between 19h and 20h. Today, I used another maintenance window, ran the update and everything went fine, no danger message, no nothing. This of course leaves me wondering: what has changed to yield 3 very different outcomes? Any changes to the update procedure and packages? If so, I can't find anything in the release notes.

Also, don't get carried away with the number of servers or pools. A large number of servers may not improve your results.

When choosing pools, it's best to learn what type of servers they're bundling. For me, I have chosen 2.de.pool.ntp.org because it includes IPv6 servers and they tend to work best for me.

Just to let everyone know: I just discovered that for the last 2 days squid has been crashing without restarting. It popped up while running ansible apt updates on a number of machines. As it turns out, squid crashes on every 3rd "apt update", wether ansible is running in parallel mode or sequentially. I have been unable to find anything in the logs nor any core dumps. Resetting nor re-installing the plugin has not helped.

Squid was only used here to work-around auto-proxy config problems debian had for a while some time ago. I solved the issue creating an interface group with the required FW rules and removed squid from the firewall.

Good advice. Of course it is best to search for <if>igb0</if> while replacing

For a while I had an old mac mini with additional thunderbolt ethernet ports as a backup for a DEC750. I used to download the config from the DEC750 and run it through sed (global search and replace tool) to replace all interface names, like "s/igb0/bge1/g" and so on. One may even map multiple interfaces from the old setup to one in the new one. Worked like a charm for me.

Just note down the interface names on the originating machine, log into a default installation on the destination machine and you'll see which interface names need to be replaced and how. Modify the config file and restore it on the new hardware. Same in your case, when changing interface adaptor cards.