Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Thomas_Dunlap
Participant
Jump to solution

Monitor VPN Tunnel Using SNMP

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
HristoGrigorov

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

12 Replies
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
Advisor

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.

0 Kudos
Pedro_Espindola
Advisor

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
HristoGrigorov

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

0 Kudos
Thomas_Dunlap
Participant

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
Advisor

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
Advisor

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
Advisor

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?

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events