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.