Monitor VPN Tunnel Using SNMP

[Thomas_Dunlap]

Check Point 730 Appliance

Version: R77.20.87 (990173004)

I have a VPN tunnel between two (2) Check Point 730 Appliances. Both have the same firmware version.  Tunnel works most of the time but occasionally it fails.  I have not been able to determine how this failure is recorded in the System logs.  Nor have I found the OID that would permit monitoring this via SNMP.  Can anyone point me in the right direction.

Cheers

[HristoGrigorov]

Hi,

Quite easy to achieve actually. All you need to do is fetch this OID:

.1.3.6.1.4.1.2620.500.9002.1.3.xxx.xxx.xxx.xxx.0

where xxx.xxx.xxx.xxx is the IP of the other gateway. Match the returned value against following table:

3 active
4 destroy
129 idle
130 phase1
131 down
132 init

[Pedro_Espindola]

Hristo, any ideas why Zabbix discovery of VPN tunnels does not work on SMB appliances?

I'm using discovery[{#SNMPVALUE},1.3.6.1.4.1.2620.500.9002.1.2]. It works fine in enterprise appliances, but not on SMB.

[HristoGrigorov]

Change OID to .1.3.6.1.4.1.2620.500.9002.1 and it shall  work.

[Pedro_Espindola]

When I do that it discovers everything in the table and the items do not work.

From https://www.zabbix.com/documentation/current/manual/discovery/low_level_discovery/snmp_oids we see the correct format is discovery[{#MACRO},<oid-of-column>], like I was using with the column tunnelPeerObjName.

The problem is that the gateway does not respond to SNMP walk on OID 1.3.6.1.4.1.2620.500.9002.1.2 or any other column. I don't know why.

root@host:/# snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.4.1.2620.500.9002.1.2

iso.3.6.1.4.1.2620.500.9002.1.2 = No Such Instance currently exists at this OID

The walk works on enterprise gateways and the discovery succeeds.

[HristoGrigorov · Accepted solution]

The following command works for me:

# snmpwalk -v 2c -On -c public 192.168.0.1 .1.3.6.1.4.1.2620.500.9002.1

I do not know if the table that is returned is what auto-discovery expects. But it is probably easy to adjust it to work.

[HristoGrigorov]

On second thought... The way VPN table is returned is a bit lame... How on earth am I supposed to enumerate table where peer IP is part of the OID ? I am almost sure auto-discovery won't be possible here. I do not understand what the author (vendor) meant to do it like that... 

[Thomas_Dunlap]

To all, many thanks I have finally got this to work. I do appreciate all that have responded

Key take away is use the snmpwalk to get it right. Now I can fine tune my PRTG.  Here are the results I found. Hopefully this will help others.  Have a nice day

----------------------- New Test -----------------------
2/28/2020 10:33:40 AM (3 ms) : Device: 192.168.0.1
2/28/2020 10:33:40 AM (5 ms) : SNMP V2c
2/28/2020 10:33:40 AM (5 ms) : Walk 1.3.6.1.4.1.2620.500.9002.1
2/28/2020 10:33:40 AM (290 ms) : 1.3.6.1.4.1.2620.500.9002.1.2. = "VPN_Site1" [ASN_OCTET_STR]
2/28/2020 10:33:41 AM (563 ms) : 1.3.6.1.4.1.2620.500.9002.1.3. = "3" [ASN_COUNTER]
2/28/2020 10:33:41 AM (832 ms) : 1.3.6.1.4.1.2620.500.9002.1.4. = "VPN_Site1_community" [ASN_OCTET_STR]
2/28/2020 10:33:41 AM (1192 ms) : 1.3.6.1.4.1.2620.500.9002.1.5 = "0.0.0.0" [ASN_IPADDRESS]
2/28/2020 10:33:42 AM (1456 ms) : 1.3.6.1.4.1.2620.500.9002.1.6. = "" [ASN_OCTET_STR]
2/28/2020 10:33:42 AM (1912 ms) : 1.3.6.1.4.1.2620.500.9002.1.7. = "0.0.0.0" [ASN_OCTET_STR]
2/28/2020 10:33:42 AM (2361 ms) : 1.3.6.1.4.1.2620.500.9002.1.8. = "0" [ASN_COUNTER]
2/28/2020 10:33:43 AM (2820 ms) : 1.3.6.1.4.1.2620.500.9002.1.9. = "0" [ASN_COUNTER]
2/28/2020 10:33:43 AM (3316 ms) : 1.3.6.1.4.1.2620.500.9002.1.10. = "1" [ASN_COUNTER]
2/28/2020 10:33:44 AM (3764 ms) : 1.3.6.1.4.1.2620.500.9002.1.11. = "1" [ASN_COUNTER]

----------------------- New Test -----------------------

2/28/2020 10:38:29 AM (7 ms) : Device: 10.99.1.3
2/28/2020 10:38:29 AM (10 ms) : SNMP V2c
2/28/2020 10:38:29 AM (12 ms) : Walk 1.3.6.1.4.1.2620.500.9002.1
2/28/2020 10:38:29 AM (22 ms) : 1.3.6.1.4.1.2620.500.9002.1.2. = "VPN_Site2" [ASN_OCTET_STR]
2/28/2020 10:38:29 AM (34 ms) : 1.3.6.1.4.1.2620.500.9002.1.3. = "3" [ASN_COUNTER]
2/28/2020 10:38:29 AM (42 ms) : 1.3.6.1.4.1.2620.500.9002.1.4. = "VPN_Site2_community" [ASN_OCTET_STR]
2/28/2020 10:38:29 AM (50 ms) : 1.3.6.1.4.1.2620.500.9002.1.5. = "0.0.0.0" [ASN_IPADDRESS]
2/28/2020 10:38:29 AM (58 ms) : 1.3.6.1.4.1.2620.500.9002.1.6. = "" [ASN_OCTET_STR]
2/28/2020 10:38:29 AM (67 ms) : 1.3.6.1.4.1.2620.500.9002.1.7. = "0.0.0.0" [ASN_OCTET_STR]
2/28/2020 10:38:29 AM (76 ms) : 1.3.6.1.4.1.2620.500.9002.1.8. = "0" [ASN_COUNTER]
2/28/2020 10:38:29 AM (89 ms) : 1.3.6.1.4.1.2620.500.9002.1.9. = "0" [ASN_COUNTER]
2/28/2020 10:38:29 AM (116 ms) : 1.3.6.1.4.1.2620.500.9002.10. = "1" [ASN_COUNTER]
2/28/2020 10:38:29 AM (125 ms) : 1.3.6.1.4.1.2620.500.9002.1.11. = "1" [ASN_COUNTER]

[HristoGrigorov]

Sweet. May be remove public IPs from output. 

[John_Fleming]

Any idea how this changes based on configuration of VPN Tunnel sharing? (device -> advanced settings -> VPN Tunnel Sharing.

I don't see any indication of what subnets are involved in the snmp options. The default is a vpn tunnel per subnet. What i'm assuming is this snmp output is showing if any vpn tunnel is up to the given peer. If that is the case I would expect this isn't as useful as it could be unless the VPN was a VTI or the tunnel sharing mode was set to gateway so that all traffic went through a single vpn tunnel vs 1 vpn tunnel per subnet (or host).

[HristoGrigorov]

Not sure but I think tunnel is considered active when both Phase 1 and Phase 2 are negotiated. For permanent tunnels it could be counting result from tunnel_test or dpd as well. 

Btw, I found sk63663 that explains exactly how VPN tunnels are supposed to be monitored via SNMP. 

[John_Fleming]

Thats kind of my point. There are 3 vpn configs that will drastically change phase II and its not clear how this is reflected via snmp.

That being said i've never looked at customizing snmpd and it looks really easy. 

[John_Fleming]

Bump:

Tunnel management can be set to 1 tunnel per gateway, 1 tunnel per network or 1 tunnel per host. These settings have a pretty massive effect on how many vpn tunnels are up between a pair. 

How can I verify tunnel configuration via snmp without just forcing everything to be 1 tunnel per gateway or is that just the only option?