Permanent/Monitored VPN tunnel(s) down-juniper-junos

Permanent/Monitored VPN tunnel(s) down-juniper-junos

Vendor: juniper

OS: junos

Description:
Some VPN tunnels are set to be permanent, or monitored, to ensure they are always up. indeni will trigger an issue if such VPN tunnels are down.

Remediation Steps:
Review the cause for the tunnels being down.
|||1. Areas to to check for possible root cause:
| a. is the remote peer up or down?
| b. verify that Phase I and Phase II configuration match on both ends
| c. is policy in place to allow traffic?
| d. NAT issues
| e. encryption domain
| f. routes
| g. firewall logs.
|2. Consider enabling debugging for the detailed information. |
|3. Review this article on Juniper tech support site: How to troubleshoot a VPN tunnel that is down or not active

How does this work?
The script runs “show configuration security ike, show configuration security ipsec, show security ipsec inactive-tunnels, show security ipsec security-associations brief” to retrieve IPSec VPN related information.

Why is this important?
The IPSec VPN state can indicate whether the IPSec VPN has been correctly configured and whether the VPN is up or down.

Without Indeni how would you find this?
An administrator won’t find the VPN being down until the users report issues. “show security ipsec inactive-tunnels, show security ipsec security-associations brief” will show the VPN status.

junos-show-security-ipsec

name: junos-show-security-ipsec
description: Retrieve VPN/ipsec information
type: monitoring
monitoring_interval: 5 minute
requires:
    vendor: juniper
    os.name: junos
    product: firewall
comments:
    vpn-tunnel-state:
        why: |
            The IPSec VPN state can indicate whether the IPSec VPN has been correctly configured and whether the VPN is up or down.
        how: |
            The script runs "show configuration security ike, show configuration security ipsec, show security ipsec inactive-tunnels, show security ipsec security-associations brief" to retrieve IPSec VPN related information.
        can-with-snmp: false
        can-with-syslog: false
steps:
-   run:
        type: SSH
        file: show-security-ipsec.remote.1.bash
    parse:
        type: AWK
        file: show-security-ipsec.parser.1.awk

cross_vendor_permanent_tunnel_down

package com.indeni.server.rules.library.core
import com.indeni.ruleengine.expressions.conditions.{And, Equals}
import com.indeni.ruleengine.expressions.core.{StatusTreeExpression, _}
import com.indeni.ruleengine.expressions.data.{SelectTagsExpression, SelectTimeSeriesExpression, TimeSeriesExpression}
import com.indeni.ruleengine.expressions.scope.ScopeValueExpression
import com.indeni.server.common.data.conditions.True
import com.indeni.server.rules._
import com.indeni.server.rules.library.{ConditionalRemediationSteps, PerDeviceRule, RuleHelper}
import com.indeni.server.sensor.models.managementprocess.alerts.dto.AlertSeverity


case class PermanentOrMonitoredVpnTunnelIsDownRule() extends PerDeviceRule with RuleHelper {

  override val metadata: RuleMetadata = RuleMetadata.builder("cross_vendor_permanent_tunnel_down", "Permanent/Monitored VPN tunnel(s) down",
    "Some VPN tunnels are set to be permanent, or monitored, to ensure they are always up. indeni will trigger an issue if such VPN tunnels are down.", AlertSeverity.ERROR,
    categories = Set(RuleCategory.HealthChecks), deviceCategory = DeviceCategory.FirewallDevices).build()

  override def expressionTree(context: RuleContext): StatusTreeExpression = {
    val actualValue = TimeSeriesExpression[Double]("vpn-tunnel-state").last
    val alwaysOn = ScopeValueExpression("always-on").visible().asString().noneable

    StatusTreeExpression(
      // Which objects to pull (normally, devices)
      SelectTagsExpression(context.metaDao, Set(DeviceKey), True),

      // What constitutes an issue
      StatusTreeExpression(

        // The additional tags we care about (we'll be including this in alert data)
        SelectTagsExpression(context.tsDao, Set("peerip", "name", "always-on"), True, Set("remote-peer-name")),

        // The case here is different compared to VpnTunnelIsDownRule, because we only take
        // the tunnels which are always on
        StatusTreeExpression(
          SelectTimeSeriesExpression[Double](context.tsDao, Set("vpn-tunnel-state"), denseOnly = false),
          And(
            Equals(actualValue, ConstantExpression(Some(0.0))),
            Equals(alwaysOn, ConstantExpression(Some("true")))
          )

          // The Alert Item to add for this specific item
        ).withSecondaryInfo(
          scopableStringFormatExpression("${scope(\"name\")} (${scope(\"peerip\")} - ${scope(\":remote-peer-name\")})"),
          scopableStringFormatExpression("This tunnel is down even though it is set to be always up."),
          title = "VPN Tunnels Affected"
        ).asCondition()
      ).withoutInfo().asCondition()

      // Details of the alert itself
    ).withRootInfo(
      getHeadline(),
      ConstantExpression("One or more VPN tunnels which should remain up is now down."),
      ConditionalRemediationSteps("Review the cause for the tunnels being down.",
        RemediationStepCondition.VENDOR_JUNIPER ->
          """|1. Areas to to check for possible root cause:
             | a. is the remote peer up or down?
             | b. verify that Phase I and Phase II configuration match on both ends
             | c. is policy in place to allow traffic?
             | d. NAT issues
             | e. encryption domain
             | f. routes
             | g. firewall logs.
             |2. Consider enabling debugging for the detailed information.
             |3. Review this article on Juniper tech support site: <a target="_blank" href="https://kb.juniper.net/InfoCenter/index?page=content&id=KB10100&actp=METADATA">How to troubleshoot a VPN tunnel that is down or not active</a>""".stripMargin
      )
    )
  }
}