Topics

Under heavy load, the log files in /var/log/filter are sometimes filling up all my disk space.

I have already configured the "maximum file size" and the "maximum preserved files" under System / Settings / Local, but the filter logs are getting much larger than they should, so this setting does not seem to have any effect on the number and size of the filter logs.

Is this behavior intended? If so, is there another way to rotate filter logs so that there is no risk of running out of disk space?

Shutting off the logs completely is no option for me.

I am using OPNsense 25.1.5_5-amd64

[<Error> -- Just ran out of space in the queue. Fatal Error. Exiting. Please file a bug report on this]

We are using the proofpoint rules and all OPNsense versions from 25.1 to 24.x are affected. Error message is:

<Error> -- Just ran out of space in the queue. Fatal Error. Exiting. Please file a bug report on this

It looks like a broken rule update is responsible for this, since ample memory and disk space is available on our boxes.

[Firewall / Settings / Advanced / Use shared forwarding]

I just found out that when using Route Based IPsec tunnels, Port Forwarding only works if

  Firewall / Settings / Advanced / Use shared forwarding

is disabled. It is enabled by default. I wonder if this is a bug or spmething that is specific to my environment. If this is by design, it should be added to the manual as it is not obvious.

This was obsered on a fresh installation of OPNsense 19.7.9.

Scenario: Private LAN on Location A connected via OPNsense 19.7.9 to Internet. OPNsense has Route-Based IPsec tunnel to location B. Everything works as expected, except that the public IP of location B is now unreachable for hosts in private LAN of location A.

I assume that all traffic from LAN to the public IP of location B is erroneously sent via Tunnel Gateway through the tunnel instead of being Natted to the standard default route.

Is this behaviour a general design flaw of Route-Based IPsec on OPNsense or can it be solved somehow?

We are evaluating OPNsense 17.1.2 for production use and observed that the snmp service is crashing regularly after about 5 days. We are sending snmp requests every five minutes for the most common linux parameters (cpu util, memory usage, interface usage, uptime) using bare OIDs, so this can't be a MIB issue.

One other thing that bothers me is that we don't get any snmp response from the standard Nagios check_snmp_storage request. All Linux hosts of different flavors give a valid reply for this SNMP query, only OPNsense does not. We could live with the fact that we can't monitor disk usage on OPNsense boxes but it is inconvenent that we have to treat these boxes seperatly from all other linux hosts.

Looks like the snmp service is dying because it's logfile growth, but this should not happen IMO. SNMPD is notoriously talkative and a quick and dirty solution would be to set the dontLogTCPWrappersConnects option. Of course this would not solve the underlying problem that it must not be possible to kill the service by sending ligitimate snmp get requests.