Messages

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.

Why would opnsense try and route traffic destined to 192.168.0.2 through the WAN?

Because all other interfaces are down at that precise moment. When an interfaces is down, the interface address and all directly connected routes are not present, anymore. So it tries to reach the syslog server via the only interface that is left.

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?

https://github.com/syslog-ng/syslog-ng/issues/3177#issuecomment-599016847

Thanks - that does seem to explain what I'm seeing.

So I know now what is causing this issue but not why.

I have a separate issue in that my LAN switch reboots every now and then and hence brings down all the VLAN interfaces. The only interface left up is the WAN.

When this happens the TCP link to the LAN syslog server expectedly goes down and when the switch comes back up and hence the syslog link comes back up, it has the WAN interface address as the source IP.

If I restart the syslog server it fixes it.

So something about the LAN links going down is causing some odd behaviour.

It's almost as though the traffic destined for the syslog server is actually going part way through NAT but I can't understand why that would be since since the syslog server address is RFC1918 (private) and it shouldn't be trying to route it through the WAN interface  - I mean is that even possible?

Why would opnsense try and route traffic destined to 192.168.0.2 through the WAN?

Does anyone have any suggestions on how to debug this further?

Best.

Update: This is still happening every few days. Looking at wireshark traces, the actual address of the router in the IP header is my external public IP (pppoe interface) instead of the LAN IP. Since the traffic is being passed out of my LAN interface I don't know how this can be happening.

Restarting either the syslog server or the router temporarily solves the issue which might suggest it's a connection setup related problem.

[TCP]

Hi,

I've got OPNsense set up to send logs over TCP to a syslog server (ELK running on Linux).

Normally the logs show up on the syslog server as coming from "_gateway" (my OPNsense router) which should resolve to the RFC1918 address assigned on the LAN interface. However just recently it changed and the host field was now showing the public IP assigned on my WAN interface which I found very odd! The syslog server shouldn't be able to see that public IP at all right?

Right when the change happened from "host:_gateway" to "host:<my public WAN IP>" there was a pause of around 1 minute and there was a "Syslog connection closed" error message. There was an "EOF occurred while idle" message immediately afterwards as well. So possibly either the syslog server crashed and/or the syslog-ng daemon on OPNsense crashed.

I've since restarted ELK and it's gone back to "host:_gateway". I also confirmed using Wireshark that the messages themselves don't actually contain any IP so I presume the syslog server is pulling this from the packet headers.

Nothing else has changed in my setup that could explain this.

Has anyone else seen this before or have any ideas how this can happen?

I think the point here is that a number of devices can perform inter-VLAN routing, not just your OPNsense box. I was advising you double check your network devices.

If you don't have a layer 3 switch set up to do that and your only router is the OPNsense one then yes, OPNsense is the only device capable of doing the inter-VLAN routing. You'd need to specifically set up rules to allow devices in different VLANs to communicate with each other as the whole point of VLANs is segregation and hence this is the default behaviour.