Messages

I'm glad I could help!

Just to check: this isn't a critical problem and I'm good to continue as is? I didn't understand the full impact of this file being missing.

The 7209fe0 commit - will that make it into tomorrow's release?

Cheers.

And with this, I'm confused even more! https://github.com/opnsense/core/issues/5841

I get this in the startup log on 25.1.12:

Code Select Expand

chown /var/run/booting .. no such file or directory
I'm on an SG-2440 and this is new since updating to 25.1.12

Anything to be concerned about?

Just too excited and can't wait I guess :)

Thanks for confirming.

Hi

I've just upgraded to 25.1.12 today.

I was presented with a major upgrade release of 25.7 on the console updater.

However doing this results in:

Code Select Expand

Fetching packages-25.7-amd64.tar: ..[fetch https://pkg.opnsense.org/FreeBSD:14:amd64/25.1/sets/packages-25.7-amd64.tar.sig: Not found] Failed, no signature found
This seems like a reasonable message given the URL isn't valid - notice the 25.1 in the URL.

Is this expected behaviour at the moment?

If so I'll just remain on 25.1.12 for now.

Thanks.

Having been reading up on Chrony I find it a bit confusing that the default port for the plugin I.e the "port" directive for the chrony.conf is UDP/323. This is supposed to be UDP/123 by default as it's the port for NTP requests. I understand it has been set like this to prevent a conflict with NTPd if run together.

According to the Chrony documentation, UDP/323 is used for the monitoring/command port which is a completely separate thing. (See section: "Command and monitoring access" -> cmdport)

I think it's going to cause confusion in the long run and looking at some posts on this forum and elsewhere it already has...

For me personally I'm trying to allow NTP requests only across the network and am trying to see if the command port is locked down by default.

Hi

I'm planning migrating my current config running on a Netgate SG-2440 to a Deciso appliance (not sure which one yet).

I suspect the hardware is different enough that it would make sense to try and work out what I have configured and set the new device up manually. To that end, is there a recommended way of extracting the "non-default" settings i.e. what I've actually set in a config to make it easier to prompt me what needs setting in the new device?

Or is it possible to just import the current config on the new device after changing the hardware NIC references?

I did have a look through Dustin's excellent write up here: https://homenetworkguy.com/how-to/migrate-opnsense-to-new-hardware/

Just looking for any thoughts on this.

Hi

Forgive me if this is a silly question but should /nonexistent (as used as a home directory for various service accounts) actually exist or not?

I removed a stale user account and it prompted me to remove /nonexistent which I just said yes to but now I can't recall if that directory had actually existed as a dummy home or not.

Thanks.

Is there any reason Deciso seem to have moved away from coreboot/SeaBIOS and instead have shifted to Insyde H2O UEFI for their appliances?

Are there any inherent advantages from a security standpoint?

I think I've found out how to do this. You can override any of the events that are listed in apccontrol with your own scripts which need to exit with a status of 99

What's odd is the killpower event has its actions commented out by default yet I'm sure the UPS went into hibernate.

Either way I just need to override the killpower event to do a —poweroff

Hope this helps others.

Hi

Is there any way to get APCUPSd to inform the UPS to power off and stay off, even when utility power returns?

I don't want my router to automatically power back up again after the UPS has switched off which seems to happen now.

E.

How would you do this when an automatically generated rule exists for WAN which essentially "lets out anything from firewall host itself" and which is put before any manually created rules?

Create a floating rule which has a higher priority than interface rules.

That seems like a solution however, shouldn't the toggle for blocking RFC1918 operate on both IN and OUT? I suspect this could be classed as a bug if it's only working on IN.

If you are using TCP with syslog, no information will be leaked, because the initial 3-way handshake always fails. UDP datagrams on the other hand might leak logged information to your ISP.

Good point.

I had that toggle active. However, after I created a floating rule with logging enabled, I found some leaking IPs because of remnants of old configurations. The WAN interface usually has the default route, so that is really no surprise.

The toggles handle only incoming RFC1918 traffic, not outgoing. You can see that in the automatic interface rule that handles only "in" packets for private/bogon IPs.

In terms of blocking all RFC1918 traffic out of the WAN then - what is the solution?

Do you have block private networks ticked on your WAN interface?

I specifically ensured this was set along with block bogons when I first set up the firewall.

However I thought that only blocked inbound as in from the Internet in my case?

So does that imply the logs are actually going out of the interface onto the public Internet? If so isn't that a security flaw?

No, the ISP will drop the packet since it is not internet routable

Would it be advisable to add a rule to the OUT side of the WAN interface to block this in my case? For me, no packets with a destination of RFC1918 should need go out that interface. In fact, the WAN interface is ultimately a PPPoE connection.