# Separate an allowed network rule from a listening destination service

> Read the individual connectivity-test findings before opening more access.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:32:36+00:00
- Modified: 2026-09-17T16:42:36+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 1 minutes

## What you need to know

Read the individual connectivity-test findings before opening more access.

## Potentially affected

Use this review for an authorized source-VM-to-destination investigation. Identify the protocol and destination port as well as both endpoint resource identities. Treat the source's example port and probe counts as illustrations, not facts about the current incident.

## DSE recommendation

DSE recommends reviewing each reported component before proposing another security exception.

## Article

## Source facts

Microsoft’s outbound-troubleshooting examples include a case where source outbound and destination inbound security rules both allow communication, yet the destination port is unreachable because the operating system is not accepting the connection. The examples separately show failures caused by source or destination rules. These results distinguish policy allowance from a listening service. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage).

## Applicability

Use this review for an authorized source-VM-to-destination investigation. Identify the protocol and destination port as well as both endpoint resource identities. Treat the source’s example port and probe counts as illustrations, not facts about the current incident.

## DSE recommendation

DSE recommends reviewing each reported component before proposing another security exception. If the relevant rules already allow the path, ask the destination owner to inspect the intended service and guest configuration. Preserve the current policy and diagnostic results. Keep the correction scoped to the observed failure rather than expanding access simply because the overall test failed.

## Verification

Repeat the same connection test after the approved correction and compare rule decisions with destination-port reachability. Confirm the intended application operation from the authorized source and check any required denial case. Record the source, destination, port and timestamps. A rule marked allowed should remain one item of evidence, not the final proof of a working service.

## Official references

[Microsoft Learn: Troubleshoot Outbound Connections](https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage).

## Primary reference

- Name: Troubleshoot Outbound Connections - Azure Network Watcher | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Separate an allowed network rule from a listening destination service,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.