Menu

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.

Show posts Menu

Messages - Isabella Borgward

#31
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".
#32
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.
#33
Logs of it not working [reply-to: default]. The source IPs are all in the "Management" alias.
#34
I guess it's this, but it's already not-disabled.
#35
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?
#36
Well that's annoying because a multi-WAN is the only use I've ever had for a floating rule  ::)  ;D
#37
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.
#38
No, it's set to default which is "all".
#39
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:
Quote
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.
#40
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.
#41
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!
#42
Just trying to find somewhere to put this...too big for pastebin, no attachments on here.
#43
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?!
#44
From this thread:
https://forum.opnsense.org/index.php?topic=33481

I got bsnmpd working, and now Zabbix is picking up readable interface names :)
#45
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.