Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - ooboyle

Pages: [1]

17.1 Legacy Series / Can I safely enable the FreeBSD repo in FreeBSD.conf on 17.1.6?

« on: May 11, 2017, 06:48:39 pm »

Running:

OPNsense 17.1.6-amd64
FreeBSD 11.0-RELEASE-p8
OpenSSL 1.0.2k 26 Jan 2017

Can I safely enable the FreeBSD repo?

I need to install py27-salt and any dependencies.

Oliver

Development and Code Review / LDAP users can't be edited for many minutes after being added

« on: September 23, 2016, 07:45:02 pm »

I've noticed a delay in being able to edit a new user added from LDAP. The user account gets created locally as expected but when I go into the account to assign it a group membership or directly assign it privileges, my changes are not saved and revert to being empty. It take over 5 minutes for this to clear and I'm still unsure if it clears on it's own or because I clicked 100 different buttons while I was waiting.

Is this a known issue?

Oliver

16.1 Legacy Series / SNMP providing faulty data to monitoring system

« on: June 06, 2016, 10:10:52 pm »

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

16.1 Legacy Series / [SOLVED] snmp not responding on multi-interface system - ESX 5.5

« on: May 31, 2016, 10:07:44 pm »

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

16.1 Legacy Series / [SOLVED] Suricata stops without logging error and won't stay started - ESX 5.5

« on: May 25, 2016, 05:50:08 pm »

Hi,

Love OPNsense so far and hope to deploy it to 70 sites in the next year but I'm having an impossible time getting Suricata to work. I'm running ESX 5.5 and using e1000 adapters on 3 interfaces.

OPNsense 16.1.14-amd64
FreeBSD 10.2-RELEASE-p17
OpenSSL 1.0.2h 3 May 2016
Latest updates are all applied

I've tried with vmxnet3 adapters as well and the service stops immediately. The e1000 adapters allow is to stay on for an hour or so before the service stops. Any change to the WAN interface (including firewall rules) causes Suricata to stop. After a reboot, the Suricata engine starts (as per the log file), but then no message is left when it stops after being left alone for a while.

Any ideas? Any assistance would be greatly appreciated.

Oliver

Pages: [1]