Project

General

Profile

Actions

Bug #13888

closed

ipsec tunnel interfaces not listed in SNMP IF-MIB on pfSense Plus

Added by Jonas Andén almost 3 years ago. Updated almost 3 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
SNMP
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.6.0
Affected Architecture:
amd64

Description

We run pfsense in several locations, primarily using pfSense Plus in AWS. We're monitoring our environment using SNMP.

One caveat with monitoring the pfSense boxes is the lack of ability to monitor the actual VPN tunnels (the VPN tunnels is the primary reason for deploying pfSense in the first place); the output in the IF-MIB simply contains a generic enc0 interface which contains the combined counters for all ipsec tunnels:

IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: wwanPP2(244)
IF-MIB::ifType.3 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.4 = INTEGER: ifPwType(246)
IF-MIB::ifType.5 = INTEGER: ilan(247)

IF-MIB::ifName.1 = STRING: ena0
IF-MIB::ifName.2 = STRING: enc0
IF-MIB::ifName.3 = STRING: lo0
IF-MIB::ifName.4 = STRING: pflog0
IF-MIB::ifName.5 = STRING: pfsync0

IF-MIB::ifAdminStatus.1 = INTEGER: up(1)
IF-MIB::ifAdminStatus.2 = INTEGER: up(1)
IF-MIB::ifAdminStatus.3 = INTEGER: up(1)
IF-MIB::ifAdminStatus.4 = INTEGER: down(2)
IF-MIB::ifAdminStatus.5 = INTEGER: down(2)

We've lived with this as a known limitation of pfSense, as this message has been communicated through the forums.

However, when scanning one of our lab instances of pfSense, running pfSense Community Edition, I noted that the community editions actually does supply ipsec tunnel tunnel data:

IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)
IF-MIB::ifType.3 = INTEGER: wwanPP2(244)
IF-MIB::ifType.4 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.5 = INTEGER: ifPwType(246)
IF-MIB::ifType.6 = INTEGER: ilan(247)
IF-MIB::ifType.7 = INTEGER: tunnel(131)
IF-MIB::ifType.8 = INTEGER: tunnel(131)
IF-MIB::ifType.9 = INTEGER: tunnel(131)
IF-MIB::ifType.10 = INTEGER: tunnel(131)
IF-MIB::ifType.11 = INTEGER: tunnel(131)
IF-MIB::ifType.12 = INTEGER: tunnel(131)

IF-MIB::ifName.1 = STRING: vtnet0
IF-MIB::ifName.2 = STRING: vtnet1
IF-MIB::ifName.3 = STRING: enc0
IF-MIB::ifName.4 = STRING: lo0
IF-MIB::ifName.5 = STRING: pflog0
IF-MIB::ifName.6 = STRING: pfsync0
IF-MIB::ifName.7 = STRING: ipsec1000
IF-MIB::ifName.8 = STRING: ipsec2000
IF-MIB::ifName.9 = STRING: ipsec3000
IF-MIB::ifName.10 = STRING: ipsec4000
IF-MIB::ifName.11 = STRING: ipsec5000
IF-MIB::ifName.12 = STRING: ipsec6000

the above output is from a 2.4.4 pfSense, so I though perhaps this had been removed in later editions, so I upgraded this old instance to 2.6.0 and produced the same results. The ipsec interfaces are named ipsec1...6 in 2.6.0, but functionality-wise the responses are identical.

So, with pfSense Plus being a commercial / paid version of pfSense CE, how come the pfSense Plus version is restricted in functionality regarding such an important area as monitoring?

Also, on another note, the tunnel interfaces always seem to have the state 'dormant(5)', no matter if they are established or not. I realise correct representation of tunnel status is a pretty complex situation for ipsec with multiple phases. My suggestion would be to simply track the Phase 1 state for ifOperStatus.

Actions

Also available in: Atom PDF