Teredo Server Detection (Nessus plugin 23972) means a host answered a Teredo router solicitation on UDP 3544, so it is acting as a Teredo server that tunnels IPv6 inside IPv4 UDP. Fix it by disabling Teredo on that host with netsh interface teredo set state disabled or the Set Teredo State GPO, then block UDP 3544 at the perimeter.
Tenable rates it Info. The real work is identifying which machine is answering and whether anything still depends on it.
What the scanner is actually detecting
Plugin 23972 is a remote, unauthenticated check in the Service detection family. According to Tenable, it sends a router solicitation to UDP 3544. If something replies, the plugin queries the Teredo server for more details, and those details show up in the plugin output.
| Scanner | Plugin ID | Title | Severity | Type |
|---|---|---|---|---|
| Nessus (Tenable) | 23972 | Teredo Server Detection | Info | Remote |
Tenable’s solution text says you can limit incoming traffic to the port if you want to, and adds: “When full IPv6 connectivity is available, the Teredo server should be disabled.” (Tenable, plugin 23972)
The plugin is looking for a server. RFC 4380 assigns UDP 3544 to Teredo servers. A Windows machine running as an ordinary Teredo client sends from a port the operating system picks (the Set Teredo Client Port policy defaults to 0, which means the OS chooses), so this plugin doesn’t normally flag ordinary client machines. The responder is usually one of these:
- A DirectAccess (Remote Access) server. Microsoft’s DirectAccess planning guide says the server needs two consecutive public IPv4 addresses so that it can act as a Teredo server for clients behind NAT.
- A Windows Server in server mode. The netsh server type exists only on Windows Server editions.
- A Linux host running miredo-server, the Teredo server daemon from the Miredo project (packaged in Debian as miredo-server).
- A firewall forwarding UDP 3544 to one of the above. In that case the IP in the report is not the machine you need to change.
Real-world risk, stated honestly
This is an informational service detection with no CVE attached. The plugin doesn’t claim the Teredo service is exploitable. The concerns are about network architecture:
- Controls that only see IPv4. Teredo carries IPv6 packets inside IPv4 UDP datagrams. Tenable’s write-up on Teredo detection points out that this traffic can get past IPv4 firewall rules, router ACLs, web proxies and IDS/IPS sensors. For the same reason, the DISA network STIG item NET-TUNL-020 requires UDP 3544 to be blocked inbound and outbound at the enclave perimeter.
- Holes through NAT. The security considerations in RFC 4380 acknowledge that Teredo lets hosts behind NAT receive traffic from the IPv6 internet. That removes the filtering NAT used to provide as a side effect.
- Spoofing and relay abuse. The RFC also covers spoofed server messages and relays being misused to hide an attacker’s address in denial-of-service attacks.
The finding doesn’t show remote code execution, credential exposure, or evidence that anyone is tunneling traffic. A DirectAccess server intentionally serving Teredo clients may warrant a documented risk acceptance. If nobody can explain why a host answers on UDP 3544, treat it as an unmanaged tunnel endpoint and turn it off.
How to confirm it on the host
On Windows, run these in an elevated PowerShell session and save the output before you change anything:
# Current Teredo type (disabled, client, enterpriseclient, server, ...)
netsh interface teredo show state
netsh interface teredo show state > C:Tempteredo-before.txt
# Same information from the NetworkTransition module
Get-NetTeredoConfiguration -PolicyStore ActiveStore | Format-List Type, ServerName
# Is anything bound to UDP 3544?
Get-NetUDPEndpoint -LocalPort 3544 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
# Is a Teredo Group Policy setting present?
Get-ItemProperty -Path 'HKLM:SOFTWAREPoliciesMicrosoftWindowsTCPIPv6Transition' -ErrorAction SilentlyContinueIf the machine has the Remote Access role, also check the DirectAccess configuration:
Get-DAServer | Select-Object TeredoStateOn Linux, find the process that owns the port:
sudo ss -ulnp 'sport = :3544'If none of these show a listener, look at the network path instead. Check whether the firewall that owns the reported IP has a static NAT or port forward for UDP 3544.
How to fix it
Windows Server in Teredo server mode
Switch the type to disabled:
netsh interface teredo set state disabledThe PowerShell equivalent writes to the persistent store by default:
Set-NetTeredoConfiguration -Type DisabledDirectAccess servers
DirectAccess manages its own Teredo setting. Turn it off with the RemoteAccess module:
Set-DAServer -TeredoState DisabledBefore you do this, make sure IP-HTTPS is working. Clients that can’t connect with 6to4 or Teredo fall back to IP-HTTPS over TCP 443. In a multisite deployment, Teredo is set per entry point, so repeat the command with -EntrypointName for each site.
Group Policy for the Windows fleet
Go to Computer Configuration > Policies > Administrative Templates > Network > TCPIP Settings > IPv6 Transition Technologies > Set Teredo State. Set the policy to Enabled, then pick the Disabled state from the drop-down. With that state, no Teredo interfaces are present on the host.
Don’t pick the policy’s own Disabled radio button. That tells Windows to use the local host setting, so a server in Teredo server mode stays in server mode.
The setting comes from tcpip.admx and writes under HKLMSoftwarePoliciesMicrosoftWindowsTCPIPv6Transition. For Intune, the same policy is exposed as ./Device/Vendor/MSFT/Policy/Config/ADMX_tcpip/Teredo_State. You can also write it into an existing GPO from PowerShell:
Set-NetTeredoConfiguration -Type Disabled -PolicyStore "contoso.comServer Baseline"Leave DirectAccess servers, and any DirectAccess clients that still rely on Teredo, out of this GPO’s scope until IP-HTTPS is confirmed. If the setting doesn’t show up on a target, work through why a GPO is not applying before you reach for local overrides.
Registry fallback (not preferred)
Microsoft documents a DisabledComponents DWORD under HKLMSYSTEMCurrentControlSetServicesTcpip6Parameters, where bit 0x08 disables Teredo interfaces. It is a bitmask, so combine it with existing bits (0x28 if Prefer IPv4, 0x20, is already set), and it needs a reboot. Microsoft warns that values other than 0 or 32 make the Routing and Remote Access service fail, so never use it on RRAS or DirectAccess servers.
Linux hosts running Miredo
Once ss shows miredo-server as the owner of UDP 3544, remove it. On Debian and Ubuntu:
sudo apt remove miredo-serverOn other distributions, stop and disable whichever unit launched the process, then remove the package.
Perimeter: block UDP 3544
On your edge firewall or perimeter router, block UDP 3544 in both directions, which is what NET-TUNL-020 asks for. The only exception is the two consecutive public addresses of a DirectAccess server that you have decided to keep serving Teredo. On individual Windows hosts, an outbound rule stops the machine from reaching public Teredo servers:
New-NetFirewallRule -DisplayName "Block outbound Teredo" -Direction Outbound -Protocol UDP -RemotePort 3544 -Action BlockAdd this to the rest of your Windows Server hardening checklist so new builds start out in the right state.
How to verify the fix and rescan
- netsh interface teredo show state now reports the type as disabled.
- Get-NetUDPEndpoint -LocalPort 3544 returns nothing.
- Get-NetTeredoState returns no object, which is how the cmdlet reports that Teredo isn’t active.
- For the GPO method, run gpupdate /force and then gpresult /scope computer /r, and confirm your GPO is in the applied list.
- For DirectAccess, Get-DAServer shows TeredoState as Disabled.
Then rerun the Nessus scan against the same IP from a scanner that can reach UDP 3544 on the target. A scan through a firewall that drops UDP 3544 comes back clean without proving anything. Finally, scan from outside to confirm the edge block.
What can break and how to roll back
- DirectAccess clients behind NAT move from Teredo to IP-HTTPS. If IP-HTTPS isn’t configured or its certificate is broken, those clients lose their connection.
- Xbox network multiplayer on Windows. Xbox Support says that without a Teredo address, multiplayer in some titles won’t connect. This matters for workstations and lab machines, rarely for servers.
- DisabledComponents requires a reboot and can break RRAS, as noted above.
To roll back, restore what you saved in teredo-before.txt, for example netsh interface teredo set state type=server. For the GPO, set Set Teredo State back to Not Configured, or run Reset-NetTeredoConfiguration -Type -PolicyStore “contoso.comServer Baseline”. For DirectAccess, run Set-DAServer -TeredoState Enabled, which only works if two consecutive public IPv4 addresses are still on the Internet interface. For Miredo, reinstall the package.
Common false positive reasons
The plugin needs a real Teredo reply, so true false positives are rare. Disputes are usually attribution or scoping problems:
- The reported IP is a firewall. A static NAT or port forward sends UDP 3544 to an internal DirectAccess server. Fix the server, or remove the forward.
- Teredo was disabled on the wrong machines. A GPO that disables the client role on workstations does nothing for the server listed in the finding.
- The setting is intentional. A DirectAccess server with Teredo enabled for NAT-bound clients is working as designed. Record it as an accepted risk rather than disputing it.
- Stale results. The scan ran before the GPO applied, or before you changed the DirectAccess configuration.
- It isn’t Windows. A Linux host running miredo-server gives the same answer. Windows settings won’t change it.
FAQ
Is Teredo still enabled by default on Windows?
Not on current clients. Microsoft states that Teredo is disabled by default in Windows 10 version 1803 and later, and its IPv6 guidance says ISATAP and Teredo are disabled by default. An explicit netsh, PowerShell or GPO setting overrides that default, though, so check the host instead of assuming.
Should I disable IPv6 entirely instead?
No. Microsoft advises against disabling IPv6 or its components because some Windows features might stop working. Disable just the transition technology you don’t need.
Is blocking UDP 3544 at the firewall enough to close the finding?
Only for scans that come from outside. An internal scanner can still reach the Teredo server, and it will keep reporting it until the service is disabled on the host itself.
Does this also disable 6to4 and ISATAP?
No. Those have their own policies (Set 6to4 State and Set ISATAP State) in the same IPv6 Transition Technologies folder. Handle them separately if your report lists them.
Tracking this finding across many hosts
With dozens of DirectAccess nodes, lab servers and Linux boxes, the hard part is proving that every responder on UDP 3544 is gone. If you use SITEY, you can upload the .nessus export, have its AI draft a host-specific script that runs through its agents on Windows and Linux endpoints only after human approval, and then re-test the individual Nessus finding to confirm it has closed. Duplicates are merged per scanner, not across scanners.