- CheckMates
- :
- Products
- :
- Quantum
- :
- SMB Gateways (Spark)
- :
- Re: Monitor VPN Tunnel Using SNMP
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Change OID to .1.3.6.1.4.1.2620.500.9002.1 and it shall work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sweet. May be remove public IPs from output.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
![](/skins/images/84DAB6BD358ECB13CE1094473F6E2961/responsive_peak/images/icon_anonymous_message.png)