Bug #13888
closedipsec tunnel interfaces not listed in SNMP IF-MIB on pfSense Plus
0%
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.
Updated by Jim Pingle almost 3 years ago
- Status changed from New to Not a Bug
There is no bug or missing data here, it's a difference in your setup between the two.
IPsec tunnels using VTI mode show up in SNMP with individual interfaces (Plus or CE) because they have distinct OS-level interfaces. The interfaces you see there are all from VTI (ipsec1000, etc).
Tunnel mode IPsec entries do not have OS level interfaces other than the shared enc0, so they do not show in SNMP.