-
Problem report
-
Resolution: Unresolved
-
Trivial
-
7.0.8, 7.2.2
-
Ubuntu 24, Zabbix 7.2.2
-
S25-W6/7, S25-W8/9
-
2
Steps to reproduce:
Create a SNMP walk item for a checkpoint firewall using these OIDs:
walk[ 1.3.6.1.4.1.2620.500.9002.1.1, 1.3.6.1.4.1.2620.500.9002.1.2, 1.3.6.1.4.1.2620.500.9002.1.3, 1.3.6.1.4.1.2620.500.9002.1.4, 1.3.6.1.4.1.2620.500.9002.1.6, 1.3.6.1.4.1.2620.500.9002.1.7, 1.3.6.1.4.1.2620.500.9002.1.8, 1.3.6.1.4.1.2620.500.9002.1.9, 1.3.6.1.4.1.2620.500.9002.1.10, 1.3.6.1.4.1.2620.500.9002.1.11 ]
Result:
On a firewall with existing S2S VPNs:
.1.3.6.1.4.1.2620.500.9002.1.1.a.a.a.a.0 = IpAddress: a.a.a.a .1.3.6.1.4.1.2620.500.9002.1.1.b.b.b.b.0 = IpAddress: b.b.b.b .1.3.6.1.4.1.2620.500.9002.1.1.c.c.c.c.0 = IpAddress: c.c.c.c .1.3.6.1.4.1.2620.500.9002.1.10.a.a.a.a.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.10.b.b.b.b.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.10.c.c.c.c.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.11.a.a.a.a.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.11.b.b.b.b.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.11.c.c.c.c.0 = Wrong Type (should be INTEGER): Gauge32: 1 .1.3.6.1.4.1.2620.500.9002.1.2.a.a.a.a.0 = STRING: "TMX_PRD_MTL" .1.3.6.1.4.1.2620.500.9002.1.2.b.b.b.b.0 = STRING: "CBID_PMI_PRD_MTL" .1.3.6.1.4.1.2620.500.9002.1.2.c.c.c.c.0 = STRING: "NASDAQ_PRD_MTL" .1.3.6.1.4.1.2620.500.9002.1.3.a.a.a.a.0 = Wrong Type (should be INTEGER): Gauge32: 3 .1.3.6.1.4.1.2620.500.9002.1.3.b.b.b.b.0 = Wrong Type (should be INTEGER): Gauge32: 3 .1.3.6.1.4.1.2620.500.9002.1.3.c.c.c.c.0 = Wrong Type (should be INTEGER): Gauge32: 3 .1.3.6.1.4.1.2620.500.9002.1.4.a.a.a.a.0 = STRING: "CDCC_TMS_CDS_MTL_VPN" .1.3.6.1.4.1.2620.500.9002.1.4.b.b.b.b.0 = STRING: "CBID_PMI_PRD_MTL_VPN" .1.3.6.1.4.1.2620.500.9002.1.4.c.c.c.c.0 = STRING: "NASDAQ_MTL_VPN" .1.3.6.1.4.1.2620.500.9002.1.6.a.a.a.a.0 = STRING: "" .1.3.6.1.4.1.2620.500.9002.1.6.b.b.b.b.0 = STRING: "" .1.3.6.1.4.1.2620.500.9002.1.6.c.c.c.c.0 = STRING: "" .1.3.6.1.4.1.2620.500.9002.1.7.a.a.a.a.0 = IpAddress: x.x.x.x .1.3.6.1.4.1.2620.500.9002.1.7.b.b.b.b.0 = IpAddress: x.x.x.x .1.3.6.1.4.1.2620.500.9002.1.7.c.c.c.c.0 = IpAddress: x.x.x.x .1.3.6.1.4.1.2620.500.9002.1.8.a.a.a.a.0 = Wrong Type (should be INTEGER): Gauge32: 0 .1.3.6.1.4.1.2620.500.9002.1.8.b.b.b.b.0 = Wrong Type (should be INTEGER): Gauge32: 0 .1.3.6.1.4.1.2620.500.9002.1.8.c.c.c.c.0 = Wrong Type (should be INTEGER): Gauge32: 0 .1.3.6.1.4.1.2620.500.9002.1.9.a.a.a.a.0 = Wrong Type (should be INTEGER): Gauge32: 0 .1.3.6.1.4.1.2620.500.9002.1.9.b.b.b.b.0 = Wrong Type (should be INTEGER): Gauge32: 0 .1.3.6.1.4.1.2620.500.9002.1.9.c.c.c.c.0 = Wrong Type (should be INTEGER): Gauge32: 0
On a firewall without active VPNs (ie an HA standby), you get a blank string instead of reporting unsupported:
Manual snmpwalk returns non-existant OID:
snmpwalk -v 2c -c public 192.168.x.x .1.3.6.1.4.1.2620.500.9002.1.1 CHECKPOINT-MIB::tunnelPeerIpAddr = No Such Instance currently exists at this OID
Since item is not reported as "unsupported", it's simply a blank string, the dependent discovery rule does not delete created items.
