As a user, I have a requirement to run a lightweight test in a specific subnet to validate that it is isolated from our internal network to ensure that there is no route to the internal network from this specific subnet.
Details
We have an external-facing subnet that has a requirement that it is isolated from our internal network. In other words, there MUST NOT be any route from this subnet to our internal network; it MUST have access to the Internet only. I am currently validating this with a lightweight monitor. This monitor shows that it fails with a DNS error and/or timeout when attempting to reach hosts on our internal network. Any other result (e.g., HTTP 2xx, 3xx, 4xx, or 5xx error) means that there is a route between this subnet and our internal network and is, therefore, a failure.
In this situation, the test is successful if the lightweight monitor fails with either a DNS or TIMEOUT error. Any other result is a failure. However, in the dashboard, a DNS or TIMEOUT error shows as a failure, and an HTTP 200 result would show a success, and alerts would be sent accordingly.
This requirement is discussed in this post in the Elastic forums.
Requested Enhancement
Add a succeeds_on_failure switch under the check object in lightweight monitors, which would negate the condition.
Use Case
As a user, I have a requirement to run a lightweight test in a specific subnet to validate that it is isolated from our internal network to ensure that there is no route to the internal network from this specific subnet.
Details
We have an external-facing subnet that has a requirement that it is isolated from our internal network. In other words, there MUST NOT be any route from this subnet to our internal network; it MUST have access to the Internet only. I am currently validating this with a lightweight monitor. This monitor shows that it fails with a DNS error and/or timeout when attempting to reach hosts on our internal network. Any other result (e.g., HTTP 2xx, 3xx, 4xx, or 5xx error) means that there is a route between this subnet and our internal network and is, therefore, a failure.
In this situation, the test is successful if the lightweight monitor fails with either a DNS or TIMEOUT error. Any other result is a failure. However, in the dashboard, a DNS or TIMEOUT error shows as a failure, and an HTTP 200 result would show a success, and alerts would be sent accordingly.
This requirement is discussed in this post in the Elastic forums.
Requested Enhancement
Add a
succeeds_on_failure
switch under thecheck
object in lightweight monitors, which would negate the condition.E.g.,