{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
        "slug": "dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service",
        "url": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/"
        },
        "title": "Separate an allowed network rule from a listening destination service",
        "summary": "Read the individual connectivity-test findings before opening more access.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-09-17T16:32:36+00:00",
        "modified_at": "2026-09-17T16:42:36+00:00",
        "reviewed_on": "2026-09-17",
        "reading_minutes": 1,
        "word_count": 216,
        "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.",
        "primary_source": {
            "name": "Troubleshoot Outbound Connections - Azure Network Watcher | Microsoft Learn",
            "url": "https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage",
            "published_on": null,
            "authority": "Microsoft Learn"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<h2>Source facts</h2>\n<p>Microsoft&#8217;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. <a href=\"https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn</a>.</p>\n<h2>Applicability</h2>\n<p>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&#8217;s example port and probe counts as illustrations, not facts about the current incident.</p>\n<h2>DSE recommendation</h2>\n<p>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.</p>\n<h2>Verification</h2>\n<p>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.</p>\n<h2>Official references</h2>\n<p><a href=\"https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Learn: Troubleshoot Outbound Connections</a>.</p>",
        "content_text": "Source facts\nMicrosoft’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.\nApplicability\nUse 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.\nDSE recommendation\nDSE 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.\nVerification\nRepeat 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.\nOfficial references\nMicrosoft Learn: Troubleshoot Outbound Connections.",
        "content_markdown": "## Source facts\n\nMicrosoft’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).\n\n## Applicability\n\nUse 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.\n\n## DSE recommendation\n\nDSE 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.\n\n## Verification\n\nRepeat 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.\n\n## Official references\n\n[Microsoft Learn: Troubleshoot Outbound Connections](https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage)."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
                "url": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-09-17"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Separate an allowed network rule from a listening destination service",
                        "item": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/#article",
                "identifier": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
                "url": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/",
                "headline": "Separate an allowed network rule from a listening destination service",
                "description": "Read the individual connectivity-test findings before opening more access.",
                "abstract": "Read the individual connectivity-test findings before opening more access.",
                "articleBody": "Source facts\nMicrosoft’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.\nApplicability\nUse 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.\nDSE recommendation\nDSE 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.\nVerification\nRepeat 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.\nOfficial references\nMicrosoft Learn: Troubleshoot Outbound Connections.",
                "datePublished": "2026-09-17T16:32:36+00:00",
                "dateModified": "2026-09-17T16:42:36+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/dse-20260917-144-separate-an-allowed-network-rule-from-a-listening-destination-service/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Separate an allowed network rule from a listening destination service"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 216,
                "timeRequired": "PT1M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "Troubleshoot Outbound Connections - Azure Network Watcher | Microsoft Learn",
                    "url": "https://learn.microsoft.com/en-us/azure/network-watcher/connection-troubleshoot-manage"
                }
            }
        ]
    }
}