Messages

1

General Discussion / Different monit settings for different gateways

« on: November 05, 2024, 12:32:21 pm »

Two routers set up in HA, two WANS /29 and /30. Standby router cannot use gateway on /30 as there aren't enough IPs, so Monit constantly complains about it being down.
Can I get Monit to ignore the /30 WAN? So long as at least one WAN works, that's "good enough".

2

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 05:21:03 pm »

OK, I was going to show the logs of it working but it looks no different, so there's no point. Drill in to it, it's the same RID. Definitely the correct rule on the correct interface.

3

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 05:18:11 pm »

Logs of it not working [reply-to: default]. The source IPs are all in the "Management" alias.

4

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 03:37:02 pm »

I guess it's this, but it's already not-disabled.

5

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 03:20:53 pm »

Deleted the floating rule. Rebooted. No different, management access does not work unless an explicit reply-to gateway is specified.

What is the "unless globally disabled" hinting at?

6

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 02:54:43 pm »

Well that's annoying because a multi-WAN is the only use I've ever had for a floating rule   

7

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 02:37:26 pm »

Yes, I started with a floating rule but it did not work, so I created individual rules.
However I just realised I left the floating rule in place, so I will remove this and re-test, in case it somehow takes precedence and breaks it.

8

24.7 Production Series / Re: reply-to: default does not seem to work as expected.

« on: October 23, 2024, 02:18:01 pm »

No, it's set to default which is "all".

9

24.7 Production Series / reply-to: default does not seem to work as expected.

« on: October 23, 2024, 01:20:26 pm »

I have two WANs. Each WAN has a gateway configured.
I want to be able to manage the firewall remotely to either public IP address.
I have spent quite a bit of time fiddling with this.
Ping works fine to both WANs. I could only get HTTPS working to one at a time.
I have found that the key to fixing this was explicitly setting a reply-to on the management access rule.
The rule consists of a source alias [a list of remote management public IPs], destination of "This Firewall" and a service of Any.
If I leave "reply to:" as "default", it doesn't work. The help for this option says:

Determines how packets route back in the opposite direction (replies), when set to default, packets on WAN type interfaces reply to their connected gateway on the interface (unless globally disabled). A specific gateway may be chosen as well here. This setting is only relevant in the context of a state, for stateless rules there is no defined opposite direction.

This makes sense - ICMP is stateless and works regardless of this setting. But HTTPS does not work unless I explicitly set reply-to to the interface's default gateway here. This contradicts what the documentation says.
There is a hint about "unless globally disabled", but what is that setting called and where is it?
Even specifying the gateway explicitly with the Gateway setting does not make this work.

10

General Discussion / Re: Monitoroing: Missing SNMP Agent support

« on: August 21, 2024, 10:58:49 am »

Comparing net-snmp and bsnmpd monitored systems side-by-side on LibreNMS, both actually provide info on system resources, so it seems like the Zabbix template is missing some OIDs in this regard.
To be clear, the screenshots are about two different systems,not the same system being monitored with different SNMP agents.
LibreNMS recognises the net-snmp one as OpnSense and bsnmpd as FreeBSD.

11

General Discussion / Re: Monitoroing: Missing SNMP Agent support

« on: August 14, 2024, 05:15:19 pm »

Probably more straightforward to just look here tbh:

https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/app/opnsense_snmp/template_app_opnsense_snmp.yaml?at=release%2F7.0

Search that page for 1.3.6.1.4.1.12325 and you will see the OIDs of interest collected by Zabbix.
I don't have the Begamot MIB installed so the 22k lines of snmpwalk output I have doesn't actually describe the metrics!

12

General Discussion / Re: Monitoroing: Missing SNMP Agent support

« on: August 14, 2024, 03:32:37 pm »

Just trying to find somewhere to put this...too big for pastebin, no attachments on here.

13

General Discussion / Re: Monitoroing: Missing SNMP Agent support

« on: August 13, 2024, 06:59:20 pm »

Yeah, you're right, bsnmpd does not return much useful for system resources.
So I had a test firewall set up with both bsnmpd and Zabbix agent, so we had interface traffic and systems resources.
Unfortunately it looks like /etc/snmpd.config got overwritten by an update [or something - it happened when I was on holiday so must have been a colleague] and was reverted to the default community string, etc. Not sure if this is the expected behaviour but if bsnmpd is "unsupported" then I guess I can expect the unexpected?!

14

23.7 Legacy Series / Re: SNMP ifDescr shows device name not description

« on: July 17, 2024, 07:03:35 pm »

From this thread:
https://forum.opnsense.org/index.php?topic=33481

I got bsnmpd working, and now Zabbix is picking up readable interface names

15

General Discussion / Re: Monitoroing: Missing SNMP Agent support

« on: July 17, 2024, 07:00:12 pm »

Supported in what sense? If it's still present and works then that'll do for me.
bsnmpd provides features that the Zabbix agent and net-snmpd does not - notably, sensible names for interfaces and firewall metrics.