Messages

Hi Bill,

The upgrade doesn't appear to make a difference.

What version of cmk are you running? Is your OPNsense install physical or virtual? If virtual, what hypervisor are you running on?

Oliver

Is this not an OPNsense-related issue? Should I be contacting someone else?

This problem persists.

I'm also not receiving SNMP data for the em0 interface...

Anyone?

Hello,

I'm running the following ESX 5.5 VM:

OPNsense 16.1.14-amd64   
FreeBSD 10.2-RELEASE-p17   
OpenSSL 1.0.2h 3 May 2016

I am using OMD/Check_MK to monitor OPNsense but I'm getting incorrect memory data back from SNMP.

As you can see from the attached graph named Check_MK.jpg (which I've confirmed is correctly showing data it extracts from the firewall via SNMP v1 and v2c using both snmpwalk and snmpbulkwalk), the system is reporting that is only has .8GB of installed RAM when in fact, it has 2GB of 'installed' RAM. The .8GB amount actually correlates to the amount of 'used' RAM which can be seen via the OPNsense dashboard attachment named OPNsense.jpg which also happens to correctly report the amount of installed RAM.

The Check_MK guys have confirmed that the faulty numbers are coming from the OPNsense system. Here's what we see with an snmpwalk and some backup information about the check being used:

.1.3.6.1.2.1.25.2.3.1.3.1 = "Real Memory Metrics"
.1.3.6.1.2.1.25.2.3.1.4.1 = 4096
.1.3.6.1.2.1.25.2.3.1.5.1 = 204196
.1.3.6.1.2.1.25.2.3.1.6.1 = 201840

Description can be found in ~/share/check_mk/checks/hr_mem:
                                    3, # hrStorageDescr
                                    4, # hrStorageAllocationUnits
                                    5, # hrStorageSize
                                    6, # hrStorageUsed

The device says (via SNMP), it's mem sitze is 204196*4096 bytes and 201840*4096 are in use. Calculate these values gives us the values Check_MK shows which means the device's SNMP values appear to be faulty.

Has anyone had this issue before? Where is OPNsense getting its 'installed' and 'used' RAM figures from?

Oliver

That said, you could strip blank spaces from the end of the string. But that might break someone's string that uses a blank space in the last position!

I wouldn't worry about it too much. The problem was due to a combination of bad cut and paste + a string with an L at the end. It was just hard to see and my fault.

Oliver

Yep. I got SNMP working yesterday so have some historical data. There doesn't seem to be any noticeable memory leak.

Doh. I figured it out. There was a very hard to see blank space at the end of my community string.

Nothing to see here. Move along...

Weust,

I wan't using that much RAM either, Right now it seems to be sitting around 41%. When I had 1GB RAM instead of 2GB, it was closer to 80-85%. High, but I didn't think it was alarming. I wasn't seeing any other performance issues.

Unfortunately, I'm having an issue getting SNMP up and running as well so I don't have any historical data at the moment.

Oliver

Ok, I've tried a number of things and SNMP simply isn't working:

1) flipped em1 and em2 so that the first LAN interface was also on the same subnet as my monitoring system
2) remove em2 entirely
3) snmpwalk for v1 and v2c from monitoring system to OPNsense

Confirmed:

1) hosts file now shows the IP of em1 for the host
2) all DNS names resolving correctly from all directions
3) firewall rules appear to be passing the traffic
4) traps from OPNsense do make it out to the monitoring system

Where is the authoritative SNMP server config file located in the file system? I found one version but it's obviously not authoritative.

Any ideas?

Oliver

Thanks, Franco. Please contact me if you need more info on my setup to reproduce.

Oliver

Hello,

I'm running on ESX5.5 using e1000 adapters for 3 interfaces on this system:

OPNsense 16.1.14-amd64   
FreeBSD 10.2-RELEASE-p17   
OpenSSL 1.0.2h 3 May 2016

em0: WAN
em1: LAN
em2: opt1

I've configured SNMP via the web ui but I'm not getting any response to my SNMP queries. I'm trying to query the em2 interface, but em1 doesn't respond either.

The hosts file resolves the hostname to em1 and I'm unable to add a second entry for the em2 interface that will persist after a reboot. My monitoring system is on the same subnet as em2. If I query em1 or em2, I don't appear to get any response at all but I do see the request being passed in the firewall log.

I suspect there are two problems here:

1) I can't query em2 because OPNsense doesn't want to resolve its own name to that interfaces IP and so breaks SNMP (I could be wrong about this, but either way, I can't seem to change that behavior so it doesn't matter).

2) I can't query em1 because OPNsense tries to process using the em2 interface and the operation breaks somewhere as a result.

Has anyone else run into this? Is there some way to resolve this other than possibly swapping the subnets associated with the em1 and em2 interfaces (I'd really prefer not to do this)?

Thanks for any assistance on the matter.

Oliver

Hi Franco,

I'm indeed reporting back with good news. The service has remained up since I last posted 5 days ago. This is a test machine and it's only passing my traffic, so we'll have to see if this becomes a moving target with more traffic. Either way, if the suricata service stops with no error at some point, it's likely just missing to RAM. Either disabling rules or adding more RAM should fix the issue.

It would be nice if there was some kind of log error we could rely on however.

Oliver

Interestingly, the service has remained up overnight. Perhaps it was simply a RAM issue.

I'll keep this thread open a little longer before confirming that.

Thanks, Bill. Your comment about RAM may have been the correct track to resolving this one.

I rebooted and added 1GB of RAM (now at 2). The service has remained started for a couple of hours. This is similar to what it did yesterday, though, so I'll report back tomorrow.