topic Re: SNMP on VSX - Location and Contact in Firewall and Security Management

SNMP on VSX - Location and Contact

JorgenSpange — Mon, 06 May 2024 10:30:29 GMT

Good day!

Been working on rolling out SNMP configuration for our checkpoint firewalls and everything is now good.
But I have one concern, which is how I can define snmp location and snmp contact for the VS's?

Per now location is not defined and contact is defined like this:

contact_1 (where the number is the vs-id)

Anyone that know how I can define this properly?

Thanks!

br

Re: SNMP on VSX - Location and Contact

PhoneBoy — Mon, 06 May 2024 16:35:29 GMT

Believe this is configured via clish on the gateway, specifically in the context of the VS.
See: https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_Gaia_AdminGuide/Topics-GAG/SNMP-Gaia-Clish.htm?Highlight=snmp

Re: SNMP on VSX - Location and Contact

Duane_Toler — Mon, 20 May 2024 18:23:07 GMT

@PhoneBoy is correct. This is per-VS on each gateway. Most likely, you will want your SNMP mode set to vs-direct-access. This lets you poll a VS directly with its VS address, rather than have to go through VS0 and set an SNMP context. Some SNMP managers may have issue with this. However, be aware that SNMP traps always will originate from VS0 with with context for the VS.

#ShamelessPlug

I have published an Ansible method to send CLISH configurations to Gaia hosts, including VSX virtual systems, in the CheckMates ToolBox contest forum. It uses a Jinja2 template to generate the configuration. You can edit the startup script to remove the "clish_cmd" as a CLI argument, and instead define 'clish_cmd' as a YAML list with your SNMP configurations. The VSID will be set automatically based on your inventory configuration. The playbook will also handle your VSX gateway cluster, to deploy the configuration for the VS on all VSX gateway hosts (each node of the cluster). Or, if you just have a single VSX gateway, that will work, too; this is defined in the inventory as well.

This could be helpful if you're looking to automate your rollout and intend to deploy across a large number of virtual systems.

Re: SNMP on VSX - Location and Contact

JorgenSpange — Tue, 08 Apr 2025 07:43:12 GMT

Thanks for the reply, guys!

Sorry for my late response..

Have to admit that it's not clear to me how you would configure something in clish on a per vs basis?

If i do vsenv and clish -c 'show configuration' it will list the snmp location and contact which is configured for VS0.

Re: SNMP on VSX - Location and Contact

Alex- — Tue, 08 Apr 2025 08:56:16 GMT

This has been subject to a few discussions, you can't easily access a context from VS0 and clish and run commands without jumping some hoops like using files and so on.

You can then go to clish from VSO, type show virtual-system all and then set virtual-system X where X is your VSID.

your prompt will change to hostname:x> meaning you're in clish for the relevant VS.

Re: SNMP on VSX - Location and Contact

JorgenSpange — Tue, 08 Apr 2025 09:53:20 GMT

Good day,

Thanks for the response.
Even though I set the vsenv as you described through clish it does not still seem to be writing the configuration for that specific vs.
If I run show configuration, the global configuration is listed and I am not able to find the snmp contact which is defined, currently as contact_3 where the number corresponds with the vs id.

Jørgen

Re: SNMP on VSX - Location and Contact

Duane_Toler — Tue, 08 Apr 2025 13:01:16 GMT

Setting "vsenv" in Bash (Expert mode) has no affect on CLISH if you try to run "clish -c ...." directly. You always have to enter CLISH, then "set virtual-system VSID". Alternatively, write a short CLISH script then execute it.

Likewise, if you SSH directly to CLISH, and run "set virtual-system VSID", then enter Expert mode, your VS is reset back to VS0 in Bash. These two have no bearing on each other (yet).

This has been fixed in R82 if you use the new VSnext mode.

(EDIT) For SNMP, you can run SNMP in several different modes. You can run one SNMP instance for all VSes or you can run a SNMP instance per-VS context. Check your SNMP mode. Details are in the VSX Admin Guide.

Re: SNMP on VSX - Location and Contact

JorgenSpange — Tue, 08 Apr 2025 12:59:39 GMT

Good day,

Yup I realized, but ssh'ing to the node and doing set virtual-system x and doing the clish config, does not seeem to work either.

Re: SNMP on VSX - Location and Contact

Duane_Toler — Tue, 08 Apr 2025 15:03:21 GMT

Yes, SNMP itself is a global item because it is closely bound to the physical host. You can't have different "contact" and "location" configurations per VS. The physical host counters (disk, IO, RAM, fans, etc.) are part of the global SNMP daemon. The Check Point product software counters (VPNs, connections, etc.) are accessed via the SNMP context (for SNMPv3) or community extension (SNMP v2c).

You can have different SNMP v3 users with access to different VS IDs, which is part of the SNMP virtualization for VSX. VS0 is one of those specific VS IDs (assuming you have "snmp mode vs" and "snmp vs-direct-access on".

What you are seeing is correct.

Re: SNMP on VSX - Location and Contact

Bob_Zimmerman — Tue, 08 Apr 2025 16:41:17 GMT

I wrote a little script which helps with that. It's also up on Github.

Re: SNMP on VSX - Location and Contact

JorgenSpange — Tue, 08 Apr 2025 21:06:30 GMT

Right, my problem would be solved if the VS' would inherit the configured snmp contact and location configured on the physical host. Instead it creates a contact with a running number and device location unset.

Re: SNMP on VSX - Location and Contact

Duane_Toler — Tue, 08 Apr 2025 21:32:46 GMT

If you're using SNMP v2c, this might be a bug. Can you also try with SNMPv3 and and use SNMP contexts to test it?

If you use snmpget or snmpwalk, then add "-n <VSID>" to the command option.

Check the jumbo HFA release notes for your version; recent HFAs had some SNMP-related fixes. You might have to run it through TAC if this is indeed a bug.

Re: SNMP on VSX - Location and Contact

JorgenSpange — Wed, 09 Apr 2025 06:19:50 GMT

I am not able to use the "-n <VSID>" as i am using: "snmp mode vs" and "snmp vs-direct-access on".
But here is the output of snmp contact when i poll the physical host and when i poll the vs.
The VS id is 3, hence the snmp contact is "contact_3":

whoami@librenms:~$ snmpwalk -v 3 -u username -l authPriv -a SHA -A password -x AES -X password 192.0.2.29 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "THIS IS THE SNMP CONTACT CONFIGURED."

whoami@librenms:~$ snmpwalk -v 3 -u username -l authPriv -a SHA -A password -x AES -X password 192.0.2.30 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "contact_3"

Also here is the output of location:
physical host:
iso.3.6.1.2.1.1.6.0 = STRING: "REGION,COUNTRY,CITY"

vs:
iso.3.6.1.2.1.1.6.0 = STRING: "Unknown"

Re: SNMP on VSX - Location and Contact

JorgenSpange — Wed, 09 Apr 2025 13:15:29 GMT

Tried to reply multiple times, but gets removed every time it seems like. Possibly cause i had the snmpwalk string copied.
I am using snmp v3.

Here is the output of snmp walk, .20 is physical host and .30 is vs. cant do -n as i have "snmp mode vs" and "snmp vs-direct-access on" configured.

whoami@librenms:~$ snmpwalk -v 3 … 192.0.2.29 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "THIS IS THE SNMP CONTACT CONFIGURED."

whoami@librenms:~$ snmpwalk -v 3 ... 192.0.2.30 1.3.6.1.2.1.1.4.0
iso.3.6.1.2.1.1.4.0 = STRING: "contact_3"

Re: SNMP on VSX - Location and Contact

Duane_Toler — Wed, 09 Apr 2025 23:47:00 GMT

I checked a VSX host of mine and got the same results. My VSX has vs-direct-access as well, but the contact OID result didn't have the trailing VSID, when querying the VS directly. Otherwise, the Location OID result was also "Unknown" like yours.

R81.20 Jumbo HFA 84

Yeah this might be a bug. Send it over to TAC for a review and hopefully they can get it escalated for you!

Re: SNMP on VSX - Location and Contact

JorgenSpange — Thu, 10 Apr 2025 10:31:39 GMT

Created a TAC case and they replied with this:
https://support.checkpoint.com/results/sk/sk166554

So seems like this is expected behaviour and will not be fixed.