ServiceNow instance is sending packets to unknown destination Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ProblemOur security team reported unusual traffic from airgapped ServiceNow servers sending packets to an unknown IP on port 443 with an unrecognized CIDR range. The issue has been observed on both prod and test systems. The IP address [::ffff:10.243.210.211:443] was identified as the destination. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } all releases Cause<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Root CauseThe traffic is internal, non-routable traffic on the network, as the IP address [::ffff:10.243.210.211] is an IPv4-mapped IPv6 address representing a private RFC 1918 address. Possible causes include MID Server communication, Discovery probe traffic, or dual-stack OS behavior. The issue is likely due to a shared configuration affecting both prod and test systems. Resolution<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Steps to Resolve Security Analysis: ServiceNow Instance Sending Packets to [::ffff:10.243.210.211]:443 Step 1: Understand What the Address Actually Is This is not a foreign or unknown IP address. The address [::ffff:10.243.210.211] is an IPv4-mapped IPv6 address — a standard notation defined in RFC 4038 and widely used in dual-stack networking environments. The ::ffff: prefix (96-bit prefix) is the standard way to represent an IPv4 address within IPv6 notation. The last 32 bits carry the IPv4 address, and many applications display those final bytes in decimal form for readability — so ::ffff:10.243.210.211 is simply a representation of the private IPv4 address 10.243.210.211. The 10.x.x.x range is an RFC 1918 private address space — meaning this is internal, non-routable traffic on your own network, not external traffic leaving your airgapped environment. Your security team's concern about an "unknown" CIDR is understandable, but the notation was likely unfamiliar to them, not the destination itself. Step 2: Why Is ServiceNow Producing This Traffic on Port 443? There are several well-established, legitimate reasons this traffic pattern occurs in ServiceNow environments: A. MID Server Communication The MID Server communicates with the ServiceNow instance exclusively via outbound HTTPS over port 443. All traffic is TLS-encrypted, and the MID Server initiates all interactions with the instance — no inbound ports are required. If your MID Server host has a dual-stack (IPv4/IPv6) OS configuration, the OS networking layer may present the IPv4 destination in IPv4-mapped IPv6 format, which is what the packet capture is showing. B. Discovery Probe Traffic ServiceNow Discovery relies on the MID Server to scan target hosts across your network. The MID Server sends probes to targets on various ports — including port 443 for HTTPS-based targets such as VMware vCenter. If 10.243.210.211 falls within a configured Discovery IP range or subnet, the MID Server would be actively probing it. C. Dual-Stack OS Behavior When a ServiceNow environment operates with IPv6 enabled, connections to IPv4 addresses may be displayed in the [::ffff:x.x.x.x] format. This is normal dual-stack behavior and does not indicate a new or separate communication channel — the traffic is still physically IPv4. Step 3: Why Both Prod and Test? This appearing on both systems strongly suggests a shared configuration is the source — most likely: A Discovery schedule targeting a subnet that includes 10.243.210.211An Integration Hub or REST outbound message configured to communicate with an internal system at that IPA shared MID Server or MID Server cluster serving both environments Step 4: Recommended Investigative Actions Immediate (within 24 hours): Identify what lives at 10.243.210.211 — Run a reverse DNS lookup or check your CMDB/asset inventory. This IP being internal means someone in your organization owns it.Review Discovery Schedules — Navigate to Discovery > Discovery Schedules and check if any IP ranges include 10.243.x.x. The Discovery Log and ECC Queue are the primary tools for monitoring what the MID Server is probing and what data is being returned.Review Outbound REST/SOAP Integrations — Check System Web Services > Outbound > REST Message for any endpoints pointing to that IP range.Check MID Server logs — Enable debug-level logging on the MID Server by setting the mid.log.level parameter to debug on the MID Server configuration record, reproduce the traffic, then grab the MID logs for review. Short-term (within 1 week): Review IP Access Control Lists — ServiceNow's IP Address Access Control feature controls which IPs can communicate with your instance, and its interaction with MID Servers has nuances worth reviewing in the context of unexpected traffic.Enforce MID Server network segmentation — Best practice is to force MID Server traffic through a secure outbound proxy for logging and inspection, and limit the MID Server to only the discovery ports required for its function. Bottom Line This is almost certainly internal, expected traffic being displayed in an unfamiliar IPv6 notation — not an external threat. 10.243.210.211 is a private RFC 1918 address. The ::ffff: prefix is standard dual-stack notation, not an obfuscation technique. That said, you should still confirm what system lives at that IP and why the MID Server or instance is communicating with it, particularly in an airgapped environment where every connection should be documented and intentional. Sources: SANS Internet Storm Center — IPv4-Mapped IPv6 Addresses (isc.sans.edu/diary/32804)ServiceNow Community — IPv6 Conversation / IPv4-mapped address format (servicenow.com/community)ServiceNow Community — MID Server and Instance Communication Security (KB0864024)ServiceNow Now Support — MID Server Prerequisites / Connections Allow List (KB0830014)ServiceNow Now Support — Discovery Troubleshooting Landing Page (KB0868418)RFC 4038 — Application Aspects of IPv6 Transition (IETF)