miredo: A Teredo (IPv6 over IPv4) tunneling daemon for creating a VPN-like connection

I don’t reach for miredo often these days — IPv6 tunneling tools have fallen out of daily use as native IPv6 has spread — but I still run into environments (older labs, specific research setups, IPv6-only assessment scope) where understanding Teredo tunneling matters. Here’s my full breakdown.

What Is miredo?

miredo is a free, open-source implementation of the Teredo protocol — a mechanism for tunneling IPv6 connectivity over IPv4 networks, including through NAT devices. Teredo was originally designed by Microsoft (RFC 4380) to let IPv6-capable hosts communicate even when sitting behind an IPv4-only NAT with no native IPv6 support.

miredo provides:

• A Teredo client — the everyday use case, giving a host behind NAT a routable IPv6 address.
• A Teredo relay — bridges native IPv6 hosts to Teredo clients.
• A Teredo server — the rendezvous point that helps Teredo clients discover each other’s NAT mappings.

Architecture and Internal Working

Teredo works by encapsulating IPv6 packets inside UDP/IPv4 datagrams. The protocol has three roles:

1. Teredo client — a host behind a NAT that wants IPv6 connectivity. It obtains a Teredo IPv6 address (in the 2001:0000::/32 prefix) derived from its Teredo server, its public IPv4 address, and its external UDP port (with those fields obfuscated via XOR to help traverse some NAT implementations).
2. Teredo server — assists in the initial “qualification” process (like STUN) so a client learns its public IP/port mapping and NAT type.
3. Teredo relay — when a Teredo client needs to talk to a native IPv6 host (or vice versa), traffic passes through a relay that de-encapsulates/re-encapsulates packets.

miredo handles NAT traversal nuances by classifying the local NAT as “cone” or “restricted” and adjusting keep-alive behavior (periodic “bubble” packets) to keep the NAT mapping alive.

Installation

sudo apt update
sudo apt install miredo

This installs both the miredo client daemon and miredo-server (if you need to run your own rendezvous server, which is rare outside research/lab contexts).

Configuration

Main config file: /etc/miredo/miredo.conf

ServerAddress teredo.remlab.net

You can point this at any public Teredo server, or your own lab-hosted one for a fully controlled test environment. Public Microsoft/Teredo servers have become less reliable over the years, so for lab work I usually stand up my own miredo-server instance.

Syntax

sudo systemctl start miredo
sudo systemctl status miredo
sudo systemctl stop miredo

Or run in the foreground for debugging:

sudo miredo -f

Complete Command Example and Output

Starting the client:

sudo systemctl start miredo
sudo systemctl status miredo

● miredo.service - Teredo IPv6 tunneling daemon
     Loaded: loaded (/lib/systemd/system/miredo.service; enabled)
     Active: active (running)

Checking the assigned Teredo IPv6 address:

ip -6 addr show teredo

5: teredo: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN
    inet6 2001:0:5ef5:79fb:2005:3a26:8bce:8e40/32 scope global
       valid_lft forever preferred_lft forever

Testing IPv6 connectivity over the tunnel:

ping6 -c 4 ipv6.google.com

PING ipv6.google.com(2404:6800:4009:820::200e) 56 data bytes
64 bytes from 2404:6800:4009:820::200e: icmp_seq=1 ttl=115 time=48.2 ms
64 bytes from 2404:6800:4009:820::200e: icmp_seq=2 ttl=115 time=47.9 ms

Verifying with tcpdump that traffic is UDP-encapsulated:

sudo tcpdump -i eth0 udp port 3544 -n

14:22:01.552341 IP 10.10.10.5.54821 > 65.55.158.118.3544: UDP, length 60
14:22:01.601119 IP 65.55.158.118.3544 > 10.10.10.5.54821: UDP, length 60

Port 3544 is the standard Teredo UDP port.

Real-World Use Case (Authorized Pentest)

Teredo/miredo shows up in my engagements almost exclusively as an egress filtering and attack-surface finding, not as a tool I actively rely on for offense:

1. During an internal assessment, I check whether Teredo is enabled by default on Windows or Linux endpoints (netsh interface teredo show state on Windows).
2. If enabled and reachable, this represents an often-overlooked IPv6 transition mechanism that can bypass IPv4-only firewall rules — traffic tunneled inside UDP/3544 sails past filters that only inspect based on IPv4 payload expectations.
3. I use miredo on a controlled test box to demonstrate establishing an IPv6 tunnel out of a segmented network, showing the client that “IPv4 egress filtering” alone is not sufficient if IPv6 transition mechanisms are left enabled.
4. Recommendation to the client: disable Teredo/6to4/ISATAP on endpoints where IPv6 isn’t explicitly needed, and ensure firewalls inspect and block outbound UDP/3544 if IPv6 connectivity isn’t sanctioned.

Automation and Integration

• Combine with tcpdump/Wireshark captures to document the tunnel establishment handshake for a report.
• Use alongside nmap -6 once the Teredo interface is up, to test IPv6-specific service exposure that might not exist on the IPv4 side of the same host.
• Scriptable via systemd for repeatable lab environment setup:

sudo systemctl enable --now miredo

Troubleshooting

• Interface never comes up / stuck in “qualifying”: the configured Teredo server may be unreachable or rate-limiting; try a different ServerAddress or host your own.
• Works on one network but not another: symmetric NATs (common on carrier-grade NAT and some corporate firewalls) break Teredo’s assumptions; Teredo fundamentally struggles behind symmetric NAT.
• No IPv6 connectivity despite interface being up: check that UDP/3544 outbound isn’t blocked somewhere in the path; Teredo needs that port free in both directions.

Best Practices

• Only enable Teredo/miredo in controlled lab or explicitly authorized testing environments — as a defender or engagement lead, treat unexplained Teredo interfaces on production endpoints as a finding to investigate.
• Prefer running your own miredo-server for lab reliability rather than depending on public Teredo relays, which have degraded significantly in availability.
• Document the security implication clearly: Teredo can create an unmonitored IPv6 path that bypasses IPv4-centric security controls.

Common Mistakes

• Assuming Teredo is dead technology and skipping the check during an assessment — it’s still enabled by default in some Windows configurations.
• Confusing Teredo with 6to4 or ISATAP; each has different NAT traversal characteristics and detection signatures.
• Forgetting that IPv6 firewall rules on the host itself may differ entirely from IPv4 rules, creating a silent gap.

FAQ

Is miredo still relevant given native IPv6 adoption? Less than a decade ago, yes — but it remains relevant as a security finding: many systems still have Teredo enabled by default even when unused, and that’s exactly the kind of overlooked attack surface worth checking for.

Does miredo work behind all NAT types? No. It works well behind cone NATs but has significant trouble with symmetric NAT, which is common in stricter enterprise environments.

Is Teredo traffic encrypted? No — Teredo only provides tunneling/encapsulation, not encryption. IPv6 traffic inside the tunnel is as protected (or unprotected) as the application layer makes it.

How do I detect Teredo tunnels as a defender? Watch for UDP traffic on port 3544 and IPv6 addresses in the 2001:0000::/32 prefix; both are strong indicators of active Teredo tunneling.

Summary

miredo is a Teredo protocol implementation that tunnels IPv6 over IPv4/UDP, primarily useful today as a demonstration and detection exercise around IPv6 transition mechanisms bypassing IPv4-focused security controls, rather than as an everyday offensive tool.

References

• miredo project page: https://www.remlab.net/miredo/
• RFC 4380 (Teredo): https://datatracker.ietf.org/doc/html/rfc4380
• Kali Linux tool page: https://www.kali.org/tools/miredo/