Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

Monitor VPN Tunnel Using SNMP

Jump to solution

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

 

1 Solution

Accepted Solutions
Highlighted
Platinum

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.

View solution in original post

11 Replies
Highlighted
Platinum

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

Highlighted

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.

Highlighted
Platinum

Change OID to .1.3.6.1.4.1.2620.500.9002.1 and it shall  work.

0 Kudos
Highlighted

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.

0 Kudos
Highlighted
Platinum

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.

View solution in original post

Highlighted
Platinum

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... 

0 Kudos
Highlighted

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]

 

 

 

Highlighted
Platinum

Sweet. May be remove public IPs from output. 

0 Kudos
Highlighted

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).

0 Kudos
Highlighted
Platinum

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. 

0 Kudos
Highlighted

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. 

0 Kudos