Amazon eero Pro 7 P2P Network Test

Amazon eero Pro 7 P2P Test: WebRTC NAT and UPnP Check

The eero Pro 7 from Amazon takes a different approach to home networking than traditional router brands: it is a Wi-Fi 7 (802.11be) mesh system designed for whole-home coverage with minimal user configuration. Each node ships with two 5G Ethernet ports and supports both wired and wireless backhaul between nodes.¹ eero prioritizes simplicity; network configuration is managed through the eero iOS or Android app rather than a traditional browser-based admin panel, which limits access to advanced NAT and port forwarding settings compared to non-mesh routers.²

For P2P and WebRTC applications, the eero Pro 7 uses restricted cone NAT. However, documented UPnP firmware bugs across multiple eero generations have caused UPnP mappings to be silently ignored or to expire prematurely, preventing gaming consoles and applications from maintaining their requested port mappings. The STUN probe on this page reveals the actual NAT type; if the probe shows inconsistent external ports or no reflexive candidates, UPnP is not functioning as expected and manual port forwarding via the eero app is required.

Specifications³

NAT type and UPnP limitations on the eero Pro 7

The eero Pro 7 does not expose a NAT mode selection in the app; it uses restricted cone NAT by default and provides no option to change to Full Cone. UPnP is enabled in the firmware but has been reported to silently fail on certain firmware versions: devices send UPnP mapping requests that appear to succeed, but the mapping is not entered in the NAT table, and inbound connections on the requested port fail. Checking the STUN probe in this tool reveals whether the actual external port is consistent; cone NAT produces matching ports, while UPnP failures show as relay ICE candidates despite a correctly configured network.⁴

Workarounds when UPnP fails on the eero Pro 7

When the STUN probe shows relay candidates despite UPnP being enabled in the eero app, the most reliable workaround is to add an explicit static port forwarding rule under Settings > Network Settings > Reservations & Port Forwarding. Assign the device a static IP reservation first so the forwarding rule does not become invalid after a DHCP lease renewal, then create a rule that maps the specific external port the application uses to the device's reserved IP. For gaming consoles that need open NAT, the eero app's DMZ equivalent (called "IP Reservations" with all ports forwarded) places the device outside the NAT restrictions, though this removes the router-level firewall for that device. If the eero app does not expose a DMZ option on your firmware version, contact eero support to confirm whether the feature is available on your hardware revision.

A secondary workaround when static forwarding is not feasible is to trigger a UPnP renewal by toggling the UPnP setting off and on in the eero app's Network Settings. This forces the router to re-evaluate all pending UPnP requests and can temporarily restore mappings that were silently dropped. The effect may last only until the next lease expiration, so this approach is best used as a diagnostic step rather than a permanent fix. CapyToolkit's STUN probe immediately reflects whether the toggle restored the external port consistency, giving you a fast feedback loop for testing whether the UPnP subsystem is responding to the reset.

WebRTC and P2P configuration on the eero Pro 7

For applications requiring specific port mappings, use the eero app's Port Forwarding section under Settings > Network Settings > Reservations & Port Forwarding. Adding a static port forwarding rule creates a permanent NAT mapping that is not subject to UPnP lease expiration. Assigning a static IP reservation to the device before adding the port forwarding rule ensures the rule remains valid if the DHCP lease renews. Furthermore, for gaming consoles, placing the console in the eero's DMZ equivalent (if the firmware version supports it) provides open NAT by forwarding all external ports to the designated device. CapyToolkit's P2P test runs from the browser on your connected device, so the ICE candidate type and reflectivity you reveal the actual network behavior your WebRTC applications will experience on the eero network.

Testing the eero Pro 7 with this tool

Connect one browser to the eero network and run the STUN probe. The probe's public IP should match the WAN IP reported in the eero app under Settings > Network Settings. If the probe shows 100.64.x.x, the ISP is applying carrier-grade NAT above the eero; contact the ISP.⁵ For mesh networks with multiple eero nodes, the node connected to the ISP gateway handles WAN routing; all downstream nodes bridge traffic through the primary node.¹ ICE candidate type should show "srflx" on working cone NAT configurations; "relay" indicates either UPnP failure or symmetric NAT upstream from the eero.

eero mesh topology and how traffic routes across nodes

In an eero mesh system, all network traffic routes through the primary gateway node: the single node connected directly to the ISP modem or ONT. Satellite nodes connect to the primary via wireless or wired backhaul and bridge all their LAN traffic through the primary for WAN processing. From the WAN's perspective, every device on every node shares the same public IP and the same NAT table maintained by the primary node. A WebRTC session on a device connected to a satellite node travels from the device to the satellite, across the backhaul to the primary, and then out the WAN to the remote peer.

Wired backhaul between nodes eliminates wireless interference and multi-hop transmission delays. On wireless backhaul, the satellite communicates with the primary over a dedicated band (typically 6 GHz on the eero Pro 7), adding approximately 1 to 3 ms per wireless backhaul hop. For a two-node system, a device on a satellite experiences 1 to 3 ms more RTT than a device connected directly to the primary. This is visible in the P2P tester as a slightly higher baseline RTT compared to a device wired to the primary gateway.

Identifying which eero node a device is connected to

The eero app shows each connected device and its associated node under Settings > Devices. If a test device shows a baseline RTT above the satellite-hop range, check whether it is connected to a satellite node rather than the primary. Moving the test device to a wired connection on the primary establishes the cleanest baseline for ISP path measurement without backhaul overhead.

IPv6 configuration on the eero Pro 7 for NAT-free WebRTC

IPv6 on the eero Pro 7 is configured under Settings > Advanced Settings > IPv6 in the eero app. The eero firmware supports IPv6 address assignment through DHCPv6 prefix delegation from the ISP and SLAAC (stateless address autoconfiguration).² Enabling IPv6 here instructs the eero gateway node to request an IPv6 prefix from the ISP's DHCP server; the eero then assigns /64 prefixes to each connected device. Devices receiving a global IPv6 address (not in the fc00::/7 ULA range or the fe80:: link-local range) can generate host candidates in WebRTC ICE negotiations, bypassing NAT entirely.

After enabling IPv6 in the eero app, verify the connected device has a global IPv6 address by running ipconfig on Windows or ifconfig on macOS and checking for an IPv6 address with a public prefix. Running the STUN probe in this tool with a global IPv6 address active returns an IPv6 address in the probe results. A WebRTC connection to another IPv6-capable endpoint then uses the host IPv6 candidate, bypassing the UPnP issues and CGNAT problems that affect IPv4 connections on the eero platform.

Verifying IPv6 reachability before relying on it for WebRTC

IPv6 connectivity from the ISP is a prerequisite for this configuration to work. The eero app shows "IPv6 not available" if the ISP's DHCP server does not respond to DHCPv6 prefix delegation requests. Not all ISPs provide IPv6 by default; some require it to be enabled on the account or modem configuration. Before relying on IPv6 to resolve eero UPnP issues, visit a dual-stack test site from the connected device to confirm end-to-end IPv6 reachability. If the test confirms IPv6 connectivity, the eero Pro 7 is providing valid global IPv6 addresses and WebRTC host candidates will work for IPv6-capable peers.

A realistic same-LAN baseline for the eero Pro 7

A device wired directly to the primary eero Pro 7 gateway node measured under 2 ms of latency with zero jitter in independent multi-console testing.⁶ In that test, a PS5 wired to the main node held the sub-2 ms, zero-jitter result while clients on a satellite node over Wi-Fi measured 8 to 12 ms, which is exactly why the primary-node wired figure is the one to anchor on.

Use that baseline, not the satellite-hop numbers discussed above, whenever the browser you are testing from sits on the primary node, and expect the avgRtt readout in this tool to land inside the 0.5 to 2 ms window on a clean wired connection. A same-LAN reading that drifts well past a couple of milliseconds on a wired connection to the primary points to something worth chasing down, whether that's a busy upload queue or a UPnP mapping that silently failed rather than normal router behavior.