Router NAT and UPnP Settings for P2P and WebRTC

Router NAT and UPnP Settings for P2P and WebRTC

Every router on this page ships with cone NAT, the kind that lets WebRTC punch a direct path between two peers. When a game lobby reports strict NAT or a video call drops to a relay anyway, the cause is almost always one of three settings: UPnP is off or failing, a security or content filter blocks STUN traffic, or the router itself sits behind a second NAT from your ISP. The fix lives in a different menu on each brand, which is why each router has its own section here.

Start with the probe, then go to the settings. In the P2P Network Tester, a consistent external port across STUN servers and an ICE candidate type of srflx mean the router allows direct traversal; different external ports mean symmetric behaviour, and a public address in the 100.64.x.x range means carrier-grade NAT above your router, which no router setting can remove. Each section gives the router's admin path for UPnP and port forwarding, its QoS option for real-time traffic, its IPv6 settings and the firmware quirks that change the result, and several include a measured same-LAN latency baseline to compare your own numbers against.

ASUS RT-BE96U P2P Network Test

The ASUS RT-BE96U is a Wi-Fi 7 (802.11be) triband router rated BE19000 across 2.4 GHz, 5 GHz, and 6 GHz bands. It ships with a 10G WAN port and a 1G WAN port, both capable of handling multi-gigabit ISP connections without a separate switch. No subscription is required for any feature; all routing, VPN, and QoS functionality is available through the ASUS ASUSWRT firmware without an ongoing fee.

For P2P and WebRTC applications, the RT-BE96U typically assigns Full Cone or Restricted Cone NAT by default, enabling ICE hole-punching to succeed for most peer configurations. The STUN probe on this page will show the same external port across multiple requests if the router is operating in cone mode. A documented firmware bug in versions up to 3.0.0.6.102 causes intermittent packet loss on the 10G WAN interface after a router reboot; probe traffic may show elevated loss for 30 to 90 seconds post-restart before the WAN driver stabilizes.¹

Specifications²

Restricted cone NAT and the NAT Type setting in ASUSWRT

The RT-BE96U defaults to restricted cone NAT for outbound connections on the WAN interface. UPnP is enabled in the ASUSWRT firmware by default; devices can request port mappings automatically, and the router opens the requested external port for the duration of the session. Disabling UPnP tightens the NAT to port-restricted cone, which still allows WebRTC ICE hole-punching but prevents gaming consoles and media devices from automatically negotiating ports. To verify the current NAT mode, log into the router admin panel at 192.168.1.1, navigate to WAN, and check the NAT Type setting. Port forwarding specific ports for known applications achieves the same result as UPnP for those applications.

When to run a same-LAN baseline before comparing connections

Before testing WebRTC performance to a remote peer, run a same-LAN baseline test with both browsers on the RT-BE96U network. This baseline captures the router's local forwarding behavior without the ISP path, revealing whether NAT restrictions or packet loss originate at the router or further upstream. If the same-LAN test shows low jitter and zero loss but the remote test shows elevated jitter, the ISP path is the cause; if both show loss, the router configuration needs adjustment before troubleshooting the ISP link.

Adaptive QoS and firmware fixes when calls fall back to relay

For the best WebRTC P2P performance, verify that UPnP is enabled in the WAN settings. If WebRTC connections consistently fall back to relay (ICE candidate type "relay" in this tool), enable Adaptive QoS and set real-time applications to highest priority; this prevents download saturation from filling the upload queue and causing STUN responses to be delayed. Furthermore, if the STUN probe shows different external ports for different STUN servers, the router may be applying a per-destination NAT mapping, and updating to the latest ASUSWRT firmware resolves most NAT anomalies. CapyToolkit's P2P tester runs over the same network path your WebRTC applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your video calls and gaming sessions will experience after you apply these configuration changes on the RT-BE96U.

Waiting out the 10G WAN driver before you probe

Connect one browser to the network served by the RT-BE96U and a second browser to a remote network. Complete the WebRTC handshake and watch the ICE candidate type; "srflx" confirms the router's NAT is permitting direct traversal. If you observe elevated packet loss immediately after rebooting the router, wait 90 seconds before starting the test to allow the 10G WAN driver to stabilize. The STUN probe public IP should match the RT-BE96U's WAN IP visible in the ASUSWRT admin panel under WAN status. Any mismatch indicates the router is behind carrier-grade NAT from the ISP. Running the STUN probe before and after a firmware update is the most reliable way to confirm the update did not change your router's NAT classification, because even minor firmware revisions can reset advanced NAT settings to their defaults on ASUS routers.

ASUSWRT-Merlin firmware and advanced P2P configuration options

ASUSWRT-Merlin is a community-maintained firmware fork for ASUS routers that extends the standard ASUSWRT interface with P2P-relevant features not available in stock firmware. The most significant addition for NAT behavior is the Full Cone NAT toggle in the WAN settings. Stock ASUSWRT uses restricted cone NAT by default and does not expose a mode toggle. Merlin firmware adds this option directly under WAN > Full Cone NAT, allowing you to change from restricted to full cone with a single toggle. Full cone NAT accepts incoming packets on any mapped external port regardless of the source IP, which resolves NAT-related ICE failures for gaming consoles and WebRTC applications that encounter restricted cone restrictions at scale.³

Merlin firmware also enables per-application QoS using Adaptive QoS on the WAN interface. This prevents background TCP transfers from causing jitter spikes on WebRTC probe traffic. Enabling Adaptive QoS in the Merlin interface and assigning the browser or gaming device to the highest-priority class produces measurably lower jitter in this tool compared to stock ASUSWRT with the default FIFO queue.

Installing ASUSWRT-Merlin on the RT-BE96U

Merlin firmware for the RT-BE96U is available from the official Merlin project page. Download the .zip file for your exact router model, navigate to Administration > Firmware Upgrade in the ASUSWRT interface, and upload the Merlin firmware file. The upgrade preserves existing settings. After the reboot, navigate to WAN and verify the Full Cone NAT option is now visible. Enable it, then rerun the STUN probe in this tool to confirm the NAT type moved from restricted cone to full cone.

Before flashing Merlin, verify that the RT-BE96U is on a supported firmware version line; the Merlin project page lists compatible ASUSWRT base versions for each router model. If the router is on an unsupported base version, you may need to flash an intermediate ASUSWRT release first, then flash Merlin on top. The Merlin forum and GitHub issues page document the exact upgrade path for each supported model, and following the documented path avoids the rare but possible scenario where a direct flash leaves the router in a state that requires recovery via TFTP.

Dual WAN failover on the RT-BE96U and WebRTC session continuity

The RT-BE96U supports dual WAN using both its 2.5G and 10G WAN ports simultaneously, with one as primary and the other as failover. When the primary WAN link fails, the router transitions new connections to the failover WAN after 12 consecutive detection failures (at the default 5-second check interval, this means approximately 60 seconds).⁴ Existing WebRTC sessions lose their ICE-negotiated candidate pair when the failover activates, because the public IP address changes when the router switches to the failover link. The ICE agent then attempts an ICE restart, re-gathering candidates from the new WAN IP.

Whether a WebRTC session recovers after failover depends on how quickly the application detects the disconnection and triggers an ICE restart. The oniceconnectionstatechange event fires with "disconnected" when the active candidate pair stops receiving responses. Well-implemented applications trigger onnegotiationneeded and initiate a new offer/answer exchange at this point, completing ICE restart within 2 to 5 seconds on a healthy failover link. Applications that do not handle ICE restart show a permanent "failed" state after failover and require the user to reload the page.

Configuring failover detection intervals for WebRTC applications

In ASUSWRT's WAN settings under Dual WAN, set the failover detection interval to its minimum (5 seconds) for WebRTC applications where fast recovery from WAN failure matters. The detection mechanism sends regular ping packets to a configured target IP (default 8.8.8.8); three consecutive failures trigger failover. Reducing the interval to 5 seconds narrows the window during which WebRTC probes fail (and loss appears in this tool) before the failover link activates.

Lab ping of 5 to 15 ms as your same-LAN reference

Independent lab testing measured client ping through the RT-BE96U at 5 to 15 ms, holding steady whether the network sat idle or carried competing wireless traffic.⁵ Treat that range as your realistic same-LAN baseline for this tool. When you run the same-LAN test here with both browsers on the RT-BE96U, check whether your reading lands inside the 5-to-15ms band that confirms the local forwarding path is healthy, since a same-LAN run measures the router's path rather than any ISP link.

The lab reached those numbers across repeated runs under both idle and congested traffic, and the figure barely moved, which is why a flat 5 to 15 ms reading is a healthy sign rather than a concern. A reading near 0 ms is not the bar to clear here; a reading well outside 5 to 15 ms is what actually signals trouble, usually Wi-Fi congestion or a saturated upload queue rather than a fault in the router's own forwarding path.

ASUS ROG Strix GS-BE18000 P2P Network Test

ASUS targets the competitive gaming segment with the ROG Strix GS-BE18000, a mesh router system carrying a BE18000 aggregate speed rating (688+5764+11529 Mbps across 2.4GHz, 5GHz, and 6GHz bands).¹ Each node ships with a 2.5G WAN port and seven 2.5G LAN ports. It runs ASUSWRT firmware with Adaptive QoS, AiMesh, and gaming-optimized features enabled by stock default. The Asuswrt-Merlin firmware community has requested support for the GS-BE18000, but the maintainer has not yet added it to the supported devices list as of mid-2026.²

For P2P and WebRTC, the ROG Strix GS-BE18000 defaults to cone NAT with UPnP enabled (standard ASUSWRT behavior). The STUN probe on this page confirms the active firmware configuration: consistent external ports across requests indicate cone behavior, while different external ports returned for different STUN servers indicate symmetric NAT that would require TURN for reliable P2P connectivity.

Specifications¹

Endpoint-independent mapping and the UPnP table

The ROG Strix GS-BE18000 uses ASUSWRT with UPnP enabled by default. ASUSWRT's default NAT filtering follows endpoint-independent behavior: the mapping is reusable across external destinations, while filtering depends on prior contact history.³ The UPnP mapping table is visible at 192.168.1.1 under WAN > UPnP, showing active port requests from LAN devices. Gaming consoles and WebRTC browsers register their required ports automatically through UPnP, and the cone NAT behavior means STUN-derived external ports remain consistent across requests. Stock ASUSWRT also provides Adaptive QoS for per-application traffic prioritization, which can reduce queuing jitter for real-time traffic when gaming or running WebRTC probes.

How AiMesh backhaul affects P2P latency on the GS-BE18000

AiMesh on the ROG Strix GS-BE18000 allows multiple ASUS routers to form a mesh network with automatic path selection for backhaul traffic. When a device connects to a satellite node instead of the primary gateway, traffic traverses the backhaul link before reaching the WAN, adding 1 to 3 ms of additional latency on wired backhaul and 5 to 15 ms on wireless backhaul depending on signal quality and band. For P2P and WebRTC applications where every millisecond of RTT matters, connecting the test device to the primary gateway node via a 2.5G LAN port produces the lowest-latency baseline. If your deployment requires the test device to connect through a satellite, quantify the backhaul contribution to RTT by running the tester once on the primary and once on the satellite, then decide whether the added latency is acceptable for your real-time application.

The backhaul contribution becomes measurable in the jitter tester when the satellite is on wireless backhaul and the signal is marginal. A 6 GHz wireless backhaul with good signal typically adds 1 to 3 ms of jitter compared to a wired connection to the primary. If you observe elevated jitter specifically on the satellite connection, run the jitter tester at different times of day; wireless backhaul jitter often correlates with neighbor Wi-Fi activity patterns, while ISP path jitter correlates with peak usage hours. This distinction helps you decide whether to invest in wired backhaul cabling or accept the wireless backhaul variance for your specific use case.

Working without a Full Cone NAT toggle on stock firmware

For stock ASUSWRT on the GS-BE18000, enable Adaptive QoS and set gaming to highest priority to reduce queuing jitter. The stock firmware's cone NAT with UPnP handles most WebRTC ICE hole-punching scenarios without manual port configuration. If you need Full Cone NAT (which accepts any inbound packet on a mapped port rather than only from previously contacted addresses), you would need a router where Merlin firmware is available, since that firmware exposes the Full Cone NAT toggle in the WAN settings on supported models. On the GS-BE18000, stock ASUSWRT's restricted cone NAT still supports P2P connectivity through UPnP and STUN, but strict NAT peers may require a TURN relay for reliable connectivity.

Comparing srflx ports from two STUN servers

Connect one browser to the ROG mesh network and a second to a remote connection. The STUN probe will show the WAN IP configured on the primary node. Stock ASUSWRT cone NAT produces consistent external ports across all STUN requests, confirming cone behavior.⁴ If the probe shows different external ports for different STUN servers, your router is behind symmetric NAT, which prevents reliable P2P connectivity without a TURN relay. You can verify this by comparing the srflx candidate ports returned by two different STUN servers: identical ports indicate cone NAT, different ports indicate symmetric NAT. Running the STUN probe before and after a firmware update is the most reliable way to confirm the update did not change your router's NAT classification, because even minor firmware revisions can reset advanced NAT settings to their defaults.

Merlin firmware and the ROG Strix GS-BE18000

ASUSWRT-Merlin firmware is not currently available for the ROG Strix GS-BE18000. The Merlin maintainer (RMerlin) adds new models conservatively, requiring Broadcom-based hardware, wide availability, frequent GPL releases from ASUS, and personal access to the hardware.² The GS-BE18000 is not listed on the official supported devices list as of mid-2026, though community members have requested support on SNBForums since mid-2025.

If Merlin support is added in the future, the installation would use ASUS's standard firmware update mechanism under Administration > Firmware Upgrade in the admin panel at 192.168.1.1. The process typically takes 3 to 5 minutes and the router is unreachable during the reboot window. After flashing, a factory NVRAM reset under Administration > Restore/Save/Upload Setting clears old configuration values that may conflict with Merlin's extended settings. Port forwarding and UPnP rules require re-entry because the NVRAM reset clears all saved configurations.

What Merlin would add if ported

On other ASUS routers where Merlin is available, the firmware adds a Full Cone NAT toggle under WAN > NAT Setting, per-application Adaptive QoS categories including dedicated rules for real-time media and gaming traffic, custom iptables rules, and IPv6 event logging in the System Log. All these settings are accessible through the standard admin panel at 192.168.1.1; Merlin does not change the admin panel URL or login process. Until Merlin is ported to the GS-BE18000, stock ASUSWRT provides the same baseline NAT and QoS behavior without these advanced options.

IPv6 configuration on the ROG Strix GS-BE18000 for NAT-free gaming

IPv6 on the ROG Strix GS-BE18000 is configured under WAN > IPv6 in the ASUSWRT admin panel. Select DHCPv6 as the connection type for ISPs providing IPv6 via DHCP prefix delegation; the router requests a prefix from the ISP and assigns globally routable addresses to LAN devices. With IPv6 active, gaming and WebRTC applications generate IPv6 host candidates that connect directly without any IPv4 NAT traversal.⁵

Xbox consoles support IPv6 for peer-to-peer connections, and Xbox Live P2P sessions over IPv6 bypass IPv4 NAT (showing Open NAT on the console).⁶ PlayStation 5 supports IPv6 at the console level, but most games still use IPv4 in practice. The original Nintendo Switch does not support IPv6; the Switch 2 added basic IPv6 in late 2025. When IPv6 is active and carries the connection, console NAT checks typically show Open or Type 1 because IPv4 NAT is no longer in the path.

Checking IPv6 prefix stability on the ROG Strix firmware

IPv6 prefix delegations have lifetimes and are renewed periodically by the ISP. Some ISPs change the delegated prefix on renewal, briefly interrupting IPv6 connectivity during the address changeover.⁵ If IPv6 connectivity appears intermittent on the GS-BE18000, checking the System Log under WAN > IPv6 for address changes around the interruption time identifies whether prefix renewal is causing the disruption rather than a firmware configuration issue.

Netgear Nighthawk RS700S P2P Network Test

Netgear positions the Nighthawk RS700S as a Wi-Fi 7 (802.11be) triband router rated BE19000, equipped with a single 10G WAN port, a matching 10G LAN port, and four 1G LAN ports. What sets this router apart from competitors in the same price range is the breadth of its VPN configuration options: OpenVPN client and server are built in, and WireGuard is available for users who prefer a modern low-overhead tunnel protocol, all without requiring Netgear's Armor subscription for basic routing features.

On P2P and WebRTC connections, the RS700S uses restricted cone NAT by default, enabling ICE hole-punching to succeed. The STUN probe on this page will show a consistent external port across requests to different STUN servers, confirming cone NAT behavior.¹ Port forwarding rules configured in the Nighthawk admin panel or through UPnP requests improve P2P connectivity for specific applications and game consoles.

Specifications²

Turning on UPnP or forwarding ports in Advanced Setup

The RS700S uses a standard restricted cone NAT configuration. UPnP is disabled by default on some firmware versions and must be explicitly enabled in the Advanced > Advanced Setup > UPnP menu. With UPnP enabled, gaming consoles and WebRTC browsers can automatically negotiate port mappings for inbound connections. Without UPnP, configure specific port forwarding rules under Advanced > Advanced Setup > Port Forwarding for applications that require incoming connections. The Nighthawk admin panel exposes per-rule NAT entry configuration, allowing precise control over which internal IP receives traffic on each forwarded port. Running the STUN probe in this tool confirms whether the UPnP mappings are actually effective for external reachability, because the probe tests the same path a remote peer would use when establishing a direct WebRTC connection through your RS700S network.

What to do when the admin panel and probe results disagree

If the Nighthawk admin panel shows UPnP enabled but the STUN probe in this tool returns a symmetric NAT classification or shows different external ports per request, the router's UPnP implementation may be failing to renew mappings before they expire. This mismatch is common on RS700S firmware versions where the UPnP lease timer is set too aggressively. Disabling and re-enabling UPnP in the admin panel forces the router to rebuild its mapping table; if the probe then shows matching external ports, the UPnP renewal timer was the cause. If the mismatch persists, configure explicit port forwarding rules for the ports your WebRTC application uses rather than relying on UPnP's dynamic allocation.

A practical workaround when UPnP renewal is unreliable is to script a periodic UPnP refresh using the router's SOAP API. A simple cron job that calls the UPnP AddPortMapping action every 30 minutes keeps the mappings alive even when the router's internal renewal timer is broken. This approach is documented in the Netgear community forums for the RS700S specifically and avoids the need to manually disable and re-enable UPnP each time you notice the NAT type drift. CapyToolkit's STUN probe can serve as the validation step in such a script: if the probe shows consistent ports, the renewal succeeded; if it shows divergence, the script triggers the SOAP refresh.

Dynamic QoS and the extra NAT layer an OpenVPN tunnel adds

For reliable WebRTC direct connections, verify that UPnP is enabled or that required ports are forwarded. Netgear's Dynamic QoS feature can be enabled to prioritize real-time UDP traffic; set it to Gaming or Streaming mode to prevent bulk transfers from saturating the upload queue and delaying STUN responses. Furthermore, if you are testing through an OpenVPN tunnel configured on the RS700S, the VPN interface adds a second NAT layer between the LAN and the tunnel exit; disable VPN tunneling for the test device to measure the actual ISP-facing NAT behavior.³ CapyToolkit's P2P tester runs over the same network path your WebRTC applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your video calls and gaming sessions will experience on the RS700S after you apply these configuration changes.

Ruling out Netgear Armor when the probe shows relay

Connect one browser to the RS700S network and a second browser to a remote connection. The STUN probe's public IP should match the WAN IP shown on the Nighthawk admin panel's Internet Status page. If the ICE candidate type shows "relay" consistently despite the router using cone NAT, check whether the Netgear Armor security subscription is intercepting HTTPS traffic in a way that disrupts signaling. Disabling Armor temporarily and retesting isolates whether the security layer is interfering with the connection path. Running the STUN probe before and after a firmware update is the most reliable way to confirm the update did not change your router's NAT classification, because even minor firmware revisions can reset advanced NAT settings to their defaults on Netgear routers.

Firmware updates on the RS700S and verifying NAT behavior afterward

Netgear releases firmware updates for the Nighthawk RS700S through the router admin panel under Administration > Router Update. The current firmware version appears on the same page alongside a check for available updates. Netgear firmware changelogs document NAT behavior changes, UPnP fixes, and security patches; reading the release notes before updating confirms whether the update addresses a specific NAT or WebRTC connectivity issue you are troubleshooting. The RS700S firmware download page at support.netgear.com lists all available versions with individual changelogs.

Firmware updates occasionally reset advanced NAT and UPnP settings to factory defaults. After updating, verify that UPnP is still enabled under Advanced > Advanced Setup > UPnP and that any port forwarding rules are still present under Advanced > Advanced Setup > Port Forwarding. Dynamic QoS settings should also be checked to confirm they are still active at the same priority configuration you set before the update.

Confirming NAT type is unchanged after a firmware update

Running the STUN probe in this tool immediately after a firmware update confirms that the update did not change the router's NAT classification. Note whether the probe shows matching or different external ports across requests before the update. After updating, rerun the probe and compare. If the probe showed matching ports before the update but shows different ports afterward, the firmware changed the NAT type from cone to symmetric; contact Netgear support with the specific before and after firmware version numbers to document the regression.

IPv6 on the Nighthawk RS700S for NAT-free P2P connections

Enabling IPv6 on the RS700S provides each connected device with a globally routable IPv6 address, eliminating IPv4 NAT traversal for WebRTC connections between IPv6-capable peers. Access IPv6 settings in the admin panel under Internet > IPv6. For residential ISP connections, DHCPv6 with prefix delegation (DHCPv6-PD) is the most reliable mode; it requests an IPv6 prefix from the ISP and assigns globally routable addresses to LAN devices from that prefix. Confirm with your ISP that IPv6 is available on your plan before enabling it on the router.

With IPv6 active on both sides of a connection, WebRTC ICE generates host candidates directly from the device's global IPv6 address. These candidates are globally reachable without STUN or TURN involvement, because IPv6 addresses require no NAT translation. The ICE candidate type in this tool shows host for an IPv6 pair rather than srflx, indicating true end-to-end connectivity without any NAT traversal layer between the two peers.⁴

Verifying IPv6 address assignment before running the P2P test

Confirming your device holds IPv6 global versus link-local fe80:: addressing comes first: on Windows, running ipconfig and looking for an address starting with 2 confirms a globally routable assignment. On macOS, ifconfig en0 shows the same information. If the device received only a link-local IPv6 address starting with fe80::, the ISP is not providing IPv6 or prefix delegation is misconfigured on the router. Disable IPv6 if it is non-functional, because incomplete IPv6 configuration can delay ICE candidate gathering by several seconds.

Borrowing the RS700 latency figures as a same-LAN reference

The model badge on the underside of this router actually reads RS700; "S" only marks the SKU that bundles a one-year Netgear Armor trial, and the hardware underneath is identical.⁵ That matters here because it lets you draw on the RS700's own published latency numbers as a same-LAN baseline. Independent testing measured client ping under 10 ms at close range, whether the network sat idle or carried competing traffic; moving further from the router pushed that figure to 12 to 16 ms.⁶ Use those figures as your reference range for this tool's same-LAN test. A reading that lands well outside them usually points to distance, wireless interference, or a saturated queue rather than a fault in the RS700S itself.

Netgear Orbi 970 P2P Network Test

Netgear's Orbi 970 occupies the premium tier of the consumer mesh market as a Wi-Fi 7 (802.11be) system. Each node ships with a 10G WAN port and 2.5G LAN ports, supporting multi-gigabit ISP connections.¹ NETGEAR Armor and Smart Parental Controls features are subscription-gated, but the NAT Filtering toggle and standard port forwarding are available in the admin interface at orbilogin.com without an Insight subscription.

For P2P and WebRTC, the Orbi 970 uses cone NAT by default with UPnP available.² Basic port forwarding is accessible without a subscription through the Orbi web interface at orbilogin.com. The STUN probe on this page reveals the actual NAT type without requiring any subscription; the probe result reflects the router's current operating configuration.

Specifications¹

The NAT Filtering toggle: Secured versus Open

The Orbi 970 supports UPnP and basic port forwarding without an Orbi Insight subscription. Access these settings at orbilogin.com under Advanced > Advanced Setup > UPnP and Port Forwarding. The UPnP table shows active mappings from LAN devices. For gaming consoles and WebRTC browsers, UPnP provides automatic port negotiation.² The Orbi 970 ships with NAT filtering set to Secured by default, which provides address-dependent filtering similar to port-restricted cone NAT.³ The NAT Filtering toggle (Open vs. Secured) is available under Advanced > Setup > WAN Setup without an Insight subscription. Setting it to Open provides endpoint-independent filtering that approximates Full Cone NAT behavior for applications that need it.

How the Orbi 970 mesh topology affects NAT behavior

In an Orbi 970 mesh system, the primary gateway node connected to the ISP modem manages the WAN-facing NAT table, and all satellite nodes bridge their LAN traffic through the primary for WAN processing. From the perspective of any external peer, devices connected to satellite nodes appear behind the same public IP and the same NAT table as devices on the primary node. The Orbi 970 uses a dedicated wireless backhaul band separate from client-facing radios, which keeps inter-node latency low and prevents the mesh hop from adding meaningful jitter to P2P traffic. For the cleanest NAT and P2P measurements on this tool, connect the test device to the primary gateway node via a 2.5G LAN port; this eliminates both wireless jitter and backhaul overhead from the reading, producing the most accurate baseline for your ISP path.

A practical test to quantify the mesh overhead is to run the P2P tester from a device on the primary node, then move the same device to a satellite node and run it again. If the STUN probe returns identical external ports and the ICE candidate type is srflx in both cases, the mesh topology is not affecting the NAT behavior. Any difference in RTT between the two runs is the pure backhaul contribution. On the Orbi 970's dedicated 5 GHz or 6 GHz backhaul band, this overhead is typically under 1 ms for wired backhaul and 2 to 5 ms for wireless backhaul with good signal, making it negligible for most WebRTC applications.

Port forwarding and the Traffic Meter without an Insight subscription

For WebRTC connections without an Orbi Insight subscription, enabling UPnP and configuring specific port forwarding rules covers most use cases. The Orbi 970's Traffic Meter under Advanced > Advanced Setup > Traffic Meter monitors total bandwidth consumption across all connected devices. While the meter does not break down traffic per application in real time, it helps identify when overall bandwidth saturation is affecting WebRTC jitter. Without Insight, standard port forwarding to a static IP provides the most reliable path for applications with known fixed ports. CapyToolkit's P2P tester runs over the same network path your WebRTC applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your video calls and gaming sessions will experience on the Orbi 970 without an Insight subscription.

Checking that Insight content filtering lets STUN through

Connect one browser to the Orbi network and a second to a remote connection. The STUN probe public IP should match the WAN IP shown on the Orbi web interface at orbilogin.com under Router Status. If Orbi Insight is active with content filtering, verify that the filter profile does not block UDP traffic to STUN port 3478 (the IANA-assigned default for STUN per RFC 8489) or port 19302 (used by Google's public STUN servers);⁴ filtering profiles that block "unknown" UDP can inadvertently prevent STUN from functioning. Disabling content filtering temporarily and retesting isolates whether Insight filtering blocks STUN from reaching the ICE candidate generation step.

Orbi 970 firmware management and subscription impact on updates

Netgear distributes firmware updates for the Orbi 970 through the orbilogin.com admin panel under Administration > Firmware Update. The admin panel checks for available firmware when the page loads and also supports triggering a manual check. Updating firmware is available without an Orbi Insight subscription; firmware releases are the same for all Orbi 970 owners regardless of subscription status. Insight subscribers gain cloud management features such as remote firmware scheduling and push notifications through the Insight Cloud Portal, but the firmware binaries themselves are not paywalled or released early to subscribers.

For P2P and WebRTC purposes, keeping firmware current at any subscription level is sufficient, because NAT behavior and UPnP reliability are addressed in general firmware releases rather than subscription-gated updates. Running the STUN probe in this tool after a firmware update confirms that the update did not change your router's NAT classification or disrupt the UPnP mappings your WebRTC applications depend on for direct connectivity.

Verifying NAT settings are intact after a firmware update

Firmware updates on Orbi systems occasionally reset advanced settings to factory defaults, particularly when the update includes significant routing engine changes. After any firmware update, verify UPnP is still enabled under Advanced > Advanced Setup > UPnP and that port forwarding rules under Advanced > Advanced Setup > Port Forwarding are intact. Running the STUN probe in this tool after the update confirms the NAT type is unchanged; consistent external ports before and after the update confirm the cone NAT configuration survived the firmware change.

IPv6 on the Netgear Orbi 970 for NAT-free P2P connectivity

IPv6 configuration on the Orbi 970 is available at orbilogin.com under Internet > IPv6.⁵ For ISPs providing IPv6 via DHCPv6 prefix delegation, select DHCPv6 and enable DHCP-PD to allow the Orbi to request an IPv6 prefix and distribute globally routable addresses to LAN devices. After enabling, the Orbi Status page under Router Status should show an active IPv6 WAN address and a delegated IPv6 LAN prefix alongside the standard IPv4 status information.

With IPv6 active, WebRTC ICE generates host candidates directly from the device's global IPv6 address. These candidates enable direct P2P connections between IPv6-capable peers without requiring IPv4 NAT traversal or TURN relay.⁶ The Orbi 970's Traffic Meter shows overall bandwidth usage but does not provide IPv6-specific breakdowns; for per-protocol analytics, a dedicated network monitoring tool at the gateway is required.

IPv6 behavior across Orbi 970 mesh satellite nodes

IPv6 prefix delegation applies to the entire Orbi mesh system. All satellite nodes bridge LAN traffic through the primary gateway node, which holds the IPv6 prefix and manages address assignment. Devices connected to satellite nodes receive global IPv6 addresses from the same delegated prefix as devices on the gateway node. No additional IPv6 configuration is required per satellite node; the IPv6 connectivity behavior for WebRTC and gaming is identical regardless of which Orbi mesh node the test device connects to.

Measured 6 GHz latency, jitter and loss at close range

Close-range testing on the 6 GHz band measured an average latency of 2.8 ms, jitter of 0.4 ms, and packet loss of 0.02 percent, with a 99th-percentile worst case of 5.2 ms.⁷ Those figures give you a concrete same-LAN baseline for this tool rather than a vague "should be low" expectation. A reading that stays within that range on your own same-LAN test confirms the Orbi 970 itself is not the bottleneck; a reading that climbs well past it, especially on packet loss, points to wireless interference or a competing bulk transfer rather than a problem with the router's forwarding path.

TP-Link Archer BE900 P2P Network Test

TP-Link's Archer BE900 sits at the top of the company's consumer router lineup as a Wi-Fi 7 (802.11be) quad-band model. The port configuration is generous even by 2026 standards: two 10G WAN/LAN ports (one RJ45 and one SFP+/RJ45 combo) alongside four 2.5G LAN ports and a single 1G LAN port¹. Management happens through the TP-Link Tether app or the web admin panel at tplinkwifi.net, both of which expose QoS by Device, port forwarding, UPnP, and DMZ settings. HomeShield, TP-Link's built-in service suite, adds content filtering and QoS tiers without requiring an ongoing subscription for basic QoS functionality².

For P2P and WebRTC, the BE900 uses port-restricted cone NAT by default. UPnP is supported and its default state varies by firmware version; check Advanced > NAT Forwarding > UPnP in the web admin panel to confirm it is enabled. The STUN probe on this page will return a consistent external IP and port across requests, confirming cone NAT behavior. Enabling QoS by Device for the test device may reduce jitter on probe traffic by prioritizing its packets over competing background transfers.

Specifications¹

The UPnP mapping table under NAT Forwarding

The BE900 supports UPnP, allowing devices to request port mappings through the router without manual configuration. Access the UPnP settings under Advanced > NAT Forwarding > UPnP in the web admin panel at tplinkwifi.net. The router maintains a UPnP mapping table showing all active port requests from LAN devices, which is useful for verifying that a gaming console or WebRTC application has successfully registered its required ports. If WebRTC connections fall back to relay despite UPnP being active, check whether a firewall rule or the router's NAT filtering is blocking the outbound UDP traffic needed for hole-punching. Running the STUN probe in this tool confirms whether the UPnP mappings are actually effective for external reachability, because the probe tests the same path that a remote peer would use when attempting to establish a direct WebRTC connection through your network.

Port forwarding versus QoS for WebRTC traffic on the BE900

Static port forwarding under Advanced > NAT Forwarding > Virtual Servers and UPnP for dynamic port mapping are both available without a HomeShield Pro subscription on the BE900. For WebRTC applications outside gaming contexts (browser-based video calls, web P2P tools), combining HomeShield QoS with UPnP or static port forwarding produces the best result: QoS prioritizes real-time media traffic while port forwarding ensures inbound connections reach the correct device. If you observe elevated jitter only when other LAN devices are active, enable QoS by Device for the test device before configuring additional port forwarding rules.

When deciding between UPnP and static forwarding, consider the application's port behavior. Applications that use fixed well-known ports (SIP on 5060/5061, specific game server ports) benefit from static forwarding because the mapping never expires. Applications that negotiate ephemeral ports per session (many WebRTC browsers, some games) work better with UPnP since the mapping adapts to the port the application actually chooses. The BE900's UPnP mapping table in the admin panel lets you verify which approach your application is using; if you see the same port requested repeatedly, static forwarding is appropriate.

SIP port forwarding and QoS by Device for calls

The BE900's web admin panel at tplinkwifi.net provides port forwarding, Port Triggering, DMZ, and UPnP under Advanced > NAT Forwarding. For WebRTC applications, standard UPnP handles dynamic port mapping without extra configuration. For VoIP applications that use fixed SIP ports (5060, 5061), adding static port forwarding rules under NAT Forwarding > Virtual Servers ensures inbound SIP traffic reaches the correct device. HomeShield QoS by Device can be configured to prioritize real-time UDP, preventing bulk downloads from adding queuing jitter to concurrent WebRTC or gaming traffic². CapyToolkit's P2P tester runs over the same network path your applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your WebRTC applications will experience after you apply these configuration changes.

Spotting carrier-grade NAT and blocked UDP port 3478

Connect one browser to the BE900 network and a second to a remote connection. The STUN probe public IP should match the WAN IP shown on the BE900 admin panel's Internet Status page. If the probe returns a 100.64.x.x address, your ISP has placed the router behind carrier-grade NAT; contact the ISP for a dedicated public IP³. The ICE candidate type should show "srflx" for standard inter-ISP connections, confirming direct NAT traversal⁴. If the candidate type shows "relay" persistently, verify that UPnP is active and no firewall rules on the BE900 block outbound UDP to port 3478.

HomeShield QoS configuration for real-time application priority

HomeShield on the Archer BE900 adds application-aware QoS controls through its Application/Mode Priority feature. HomeShield QoS classifies traffic by application type and assigns bandwidth priority by device or application category. Configuring real-time media (WebRTC, VoIP, video conferencing) to the highest priority tier prevents bulk file transfers and streaming video downloads from filling the upload queue and causing queuing jitter for concurrent real-time traffic. Access HomeShield QoS settings in the BE900 admin panel at tplinkwifi.net or the TP-Link Tether app under HomeShield > QoS.

The device list in HomeShield QoS shows all active LAN devices with their current bandwidth consumption; assign the device running WebRTC or gaming applications to the high-priority tier. HomeShield also provides comprehensive reports including per-device internet usage overview and online time analysis, which helps identify which background device is consuming bandwidth and causing jitter on an active call.

Port forwarding versus QoS for WebRTC traffic on the BE900

The BE900 provides static port forwarding under Advanced > NAT Forwarding > Virtual Servers and UPnP for dynamic port mapping, both available without a HomeShield Pro subscription. HomeShield QoS covers application-aware classification including video conferencing and VoIP alongside gaming traffic. For WebRTC applications outside gaming contexts (browser-based video calls, web P2P tools), combining HomeShield QoS with UPnP or static port forwarding produces the best result: QoS prioritizes real-time media traffic while port forwarding ensures inbound connections reach the correct device.

IPv6 on the Archer BE900 for NAT-free WebRTC connections

The Archer BE900 supports IPv6 through the admin panel under Advanced > IPv6. For residential ISP connections, select DHCPv6 in the IPv6 mode dropdown and enable prefix delegation to allow the router to assign globally routable IPv6 addresses to LAN devices from the ISP-provided prefix. After enabling, connected devices receive IPv6 addresses alongside their IPv4 DHCP addresses. Confirm with your ISP that IPv6 prefix delegation is available before enabling it on the router.

IPv6 connectivity changes WebRTC ICE candidate behavior significantly. On a dual-stack connection, RFC 8421 recommends intermingling IPv4 and IPv6 ICE candidates so that connectivity checks run for both address families concurrently rather than sequentially⁵. This prevents a broken or incomplete IPv6 path from blocking the entire connection setup. When IPv6 works, direct IPv6 host candidates can produce lower RTT than IPv4 server-reflexive candidates because they avoid NAT traversal entirely.

Verifying IPv6 is functional before running the P2P test

After enabling IPv6 on the BE900, check for a global address, not an fe80 one, before running the P2P test. An address starting with 2 (not fe80::) via ipconfig on Windows confirms the assignment. If the device received only a link-local address, the ISP does not provide IPv6 or prefix delegation is not configured correctly. Disable IPv6 on the router if it is non-functional, because a misconfigured IPv6 path can delay ICE candidate gathering while the browser waits for connectivity checks to time out before falling back to IPv4.

TP-Link Archer GE800 P2P Network Test

Designed specifically for competitive gaming, the TP-Link Archer GE800 has become the top-selling gaming router on Amazon as of mid-2026. The hardware includes two 10G WAN/LAN ports and four 2.5G LAN ports, while the admin interface caters to gamers with Game Acceleration QoS, Game Port Forwarding, a Dedicated Gaming Port, and Game Panel traffic monitoring¹. RGB lighting and a gaming-oriented design place it in the gaming peripherals segment rather than the mainstream networking category.

For P2P and WebRTC, the GE800 uses cone NAT by default with UPnP enabled, matching the open NAT behavior gaming routers emphasize. The STUN probe on this page will show a stable external IP with consistent port assignments across requests, confirming cone NAT behavior. Configuring the GE800's Game Port Forwarding with specific ports for a game or WebRTC application locks in the port mapping permanently, avoiding UPnP lease expiration that occasionally drops gaming sessions.

Specifications¹

Game Port Forwarding for mappings that outlast UPnP leases

The GE800 prioritizes open NAT for gaming. UPnP is enabled by default and the router maintains a UPnP status page under Advanced > NAT Forwarding > UPnP showing all active port mappings from LAN devices, which is useful for verifying that a gaming console's port requests are being honored. Game Port Forwarding under Game Center > Game Port Forwarding adds static mappings for known games, ensuring the port remains open even when the UPnP lease expires or the game does not support UPnP². Access the full admin panel at 192.168.0.1 or tplinkwifi.net for these settings. The combination of cone NAT and UPnP means most WebRTC applications will establish direct connections without requiring manual port forwarding, which is why the GE800 is a popular choice for gamers who also rely on video conferencing and streaming tools that depend on WebRTC.

When to use the Dedicated Gaming Port versus UPnP

The GE800 includes a Dedicated Gaming Port on the rear panel that bypasses the router's internal switch fabric for a single wired device, reducing local forwarding latency by a fraction of a millisecond compared to the standard 2.5G LAN ports. For competitive gaming where every microsecond of local latency matters, connect the gaming PC or console directly to the Dedicated Gaming Port and enable Game QoS for that port. For WebRTC applications that rely on UPnP for dynamic port mapping, leave the gaming device on a standard LAN port so the UPnP mapping table can track its port requests correctly; the Dedicated Gaming Port does not interfere with UPnP, but the QoS priority is easier to assign to a specific LAN device in the Game Center interface.

Game QoS and port triggering for real-time traffic

For WebRTC connections, the GE800's standard UPnP and cone NAT configuration is sufficient. The Game QoS feature prioritizes UDP traffic, reducing queuing jitter for real-time applications including WebRTC data channels and VoIP. Consequently, enabling Game QoS and assigning the browser or gaming device to the high-priority tier ensures that probe packets and real-time data are not delayed by competing background downloads. Port triggering, available under NAT Forwarding > Port Triggering, opens inbound ports automatically when the router detects a specific outbound port, useful for games that use non-standard signaling ports. CapyToolkit's jitter tester runs over the same UDP path that your WebRTC applications use, so the readings you see here reflect the actual jitter your voice calls and video conferences will experience after you enable Game QoS on this router.

What srflx and a 100.64 address mean on a gaming router

Connect one browser to the GE800 network and a second to a remote connection. The STUN probe should return a consistent external IP matching the GE800's WAN IP. With UPnP enabled and cone NAT active, the ICE candidate type should show "srflx" for inter-ISP connections, confirming the gaming-oriented NAT configuration is working correctly³. If the probe shows 100.64.x.x as the public IP, the GE800 itself is behind carrier-grade NAT from the ISP; the router cannot fix CGNAT⁴. The GE800 uses Wi-Fi 7 (802.11be) with 320 MHz channels on the 6 GHz band, providing lower latency and higher throughput than Wi-Fi 6E routers.

Port triggering versus static port forwarding on the Archer GE800

Static port forwarding (configured under Advanced > NAT Forwarding > Virtual Servers) permanently maps an external port to a specific internal IP:port pair. The mapping is always active, accepting inbound connections on that port at any time, which makes static forwarding the correct choice for servers, WebRTC applications that need a consistent inbound port, and gaming consoles that use the same ports across every session. Port triggering (Advanced > NAT Forwarding > Port Triggering) opens an external port dynamically when the router detects outbound traffic on a trigger port and closes the mapping automatically after the session ends.

Port triggering suits applications that use different ports each session and cannot use UPnP, because it allows inbound connections on a dynamic port without requiring the user to know the port number in advance. The limitation is that only one LAN device can use a triggered mapping at a time; two gaming consoles running the same application simultaneously cannot share a triggered mapping and require static forwarding or UPnP instead.

Setting up Game Port Forwarding profiles on the GE800

Access Game Center > Game Port Forwarding in the GE800 admin panel at 192.168.0.1 or tplinkwifi.net. This interface provides pre-built profiles for common gaming applications including PlayStation Network, Xbox Live, and specific game titles². Selecting a profile automatically populates the external and internal port ranges without requiring manual port number lookup. For WebRTC applications not in the pre-built list, use the Virtual Servers interface and add the application's UDP port range manually. Assign the target device a static IP reservation before creating the forwarding rule to prevent it from becoming invalid after a DHCP lease renewal.

Wi-Fi 7 6 GHz band performance for gaming and WebRTC devices

The Archer GE800's 6 GHz band provides lower wireless jitter than 2.4 GHz and typically lower jitter than 5 GHz for nearby devices. As a Wi-Fi 7 router, the GE800 supports 320 MHz channels on the 6 GHz band (5.925 to 7.125 GHz), doubling the channel width available to Wi-Fi 6E routers. The 6 GHz band is available exclusively to Wi-Fi 6E and Wi-Fi 7 clients, which means no legacy 2.4 GHz or 5 GHz-only devices occupy the channel. Neighboring network interference is rare on 6 GHz because fewer routers operate in this band as of 2026. Wide channel availability combined with low interference density and Wi-Fi 7 features like Multi-Link Operation typically produces wireless jitter of 1 to 3 ms on 6 GHz, compared to 5 to 15 ms on a congested 2.4 GHz channel.

For gaming devices and WebRTC applications on the same local network, using the 6 GHz band reduces the wireless jitter contribution in this tool's measurements. Connect your test device to the GE800's 6 GHz SSID and compare jitter readings against the 2.4 GHz and 5 GHz SSIDs using the jitter tester. The 6 GHz reading provides the lowest wireless-layer jitter baseline achievable on the GE800 hardware. Note that the 6 GHz band has shorter effective range than 5 GHz; devices at the edge of coverage may experience higher jitter than devices in the same room as the router.

Verifying the 6 GHz connection is active before testing

On Windows 11, open Network Settings and view the active Wi-Fi connection details to confirm the band shows 6 GHz. On macOS, hold Option and click the Wi-Fi menu icon to see channel and band information. The GE800's admin panel under Wireless shows which band each connected device is using. To verify 6 GHz, not a stale 2.4 GHz link, rather than trusting a device that may have fallen back to a saved 2.4 GHz credential, confirms the jitter reading actually reflects 6 GHz band performance. Running the jitter test on the 6 GHz band typically shows lower wireless jitter than 2.4 GHz because the 6 GHz band has fewer competing neighboring networks and wider channel availability, which produces a cleaner baseline reading for your P2P latency measurements.

If the device shows it is connected to 5 GHz or 2.4 GHz instead of 6 GHz, forget the network and reconnect while standing near the router to force a fresh band selection. Some devices cache their preferred band based on signal strength history and may not roam to 6 GHz automatically even when the 6 GHz signal is stronger. The GE800's band steering feature (enabled by default under Wireless > Smart Connect) helps guide devices to the optimal band, but manual verification is the only way to be certain the jitter test is running on the intended band.

Sub-10 ms ping at close and long range

Independent testing measured client ping through the GE800 in the sub-10 ms range at both close and long range, whether or not other traffic loaded the network at the time.⁵ Treat that figure as your realistic same-LAN baseline when you run this tool between two browsers on the GE800's network. A reading that lands well above 10 ms on a same-LAN test is what deserves a second look, not a reading of a few milliseconds; that kind of gap usually traces back to Wi-Fi distance or a busy upload queue rather than a fault in the router's own forwarding path.

TP-Link Deco BE63 P2P Network Test

TP-Link's Deco BE63 earned RTINGS' 2026 best overall mesh router designation by delivering strong performance across coverage, throughput consistency, and ease of setup.¹ Each node ships with four 2.5G Ethernet ports and supports both wired and wireless backhaul for whole-home coverage.² Configuration is handled through the Deco app (iOS/Android) and optionally through a browser interface at 192.168.68.1, providing more NAT configuration access than competing app-only mesh systems.³

For P2P and WebRTC, the Deco BE63 uses restricted cone NAT.⁴ UPnP is supported and generally reliable in the Deco BE63 firmware generation, without the UPnP failures documented on some eero versions. The STUN probe on this page will return a consistent external port across requests, confirming the cone NAT classification.⁴ TP-Link HomeShield provides QoS without requiring a paid subscription for the basic QoS tier.¹

Specifications²

Checking UPnP mappings in the browser admin panel

The Deco BE63 enables UPnP by default. The UPnP status table is visible in the advanced browser admin panel at 192.168.68.1 under Advanced > NAT Forwarding > UPnP, showing all active port mappings from LAN devices.³ This access distinguishes the Deco BE63 from app-only mesh systems; you can directly verify whether a gaming console's UPnP request was honored. Port forwarding rules configured under NAT Forwarding > Virtual Servers persist across router restarts and DHCP lease renewals. Assigning a static IP reservation to the target device before adding port forwarding rules ensures the rule remains accurate. Running the STUN probe in this tool confirms whether the UPnP mappings are actually effective for external reachability, because the probe tests the same path a remote peer would use when establishing a direct WebRTC connection through your Deco network.

Using the browser admin panel for NAT diagnostics

The Deco BE63's browser admin panel at 192.168.68.1 exposes NAT diagnostics that the mobile Deco app does not surface. Under Advanced > NAT Forwarding > UPnP, the full UPnP mapping table shows every active port request including the internal device, requested external port, and lease expiration time. This visibility lets you confirm whether a WebRTC application's port mapping is still active or has expired without waiting for a connection failure. The browser panel also logs NAT table events under System > Log, so you can trace when a specific port mapping was created or removed. If the STUN probe in this tool shows a symmetric NAT classification but the UPnP table shows active mappings, the ISP is applying a second NAT layer above the Deco; contact the ISP to request a public IP or enable IPv6 to bypass the CGNAT restriction.

A practical diagnostic workflow is to run the STUN probe, then immediately check the UPnP table in the browser admin panel. If the probe shows matching external ports and the UPnP table shows active mappings for the test device, the NAT configuration is working correctly. If the probe shows relay or symmetric NAT but the UPnP table shows mappings, the ISP CGNAT layer is the bottleneck and enabling IPv6 on the Deco is the fastest path to direct connectivity. If the UPnP table is empty despite the application requesting ports, the UPnP request is being silently dropped and static port forwarding is the required workaround.

HomeShield priority and wired backhaul for lower jitter

For consistent WebRTC connections, verify UPnP is enabled and check the browser admin panel to confirm port mappings are being created. HomeShield QoS can be configured to prioritize real-time UDP; assign the device running WebRTC or gaming applications to the highest-priority traffic class. The Deco mesh backhaul (wired or wireless) adds a small processing hop within the mesh, but this is typically under 1 ms on wired backhaul. Consequently, connecting the primary gateway node directly to the ISP and using wired backhaul between mesh nodes produces the lowest latency and jitter for P2P applications. CapyToolkit's P2P tester runs over the same network path your applications use, so the ICE candidate type and RTT you see here reflect the actual connectivity your WebRTC applications will experience on the Deco BE63.

Why every node routes through the primary Deco

Connect one browser to the Deco network and a second to a remote connection. The STUN probe public IP should match the WAN IP in the Deco app under More > Advanced > IPv4. If the probe shows 100.64.x.x, carrier-grade NAT from the ISP is present above the Deco. The ICE candidate type should show "srflx" on a well-configured Deco BE63 with cone NAT active.⁵ For multi-node deployments, the primary gateway node handles all WAN routing; satellite nodes relay traffic through the primary regardless of wireless or wired backhaul configuration. The STUN probe in this tool is particularly useful for Deco deployments because it reveals whether the mesh topology is affecting the NAT behavior your external peers observe when they attempt to connect to your network.

HomeShield QoS real-time traffic prioritization on the BE63

The Deco BE63's HomeShield QoS assigns traffic to priority tiers based on device classification and traffic type. Configuring QoS for P2P applications requires assigning the device running WebRTC or gaming software to the Streaming or Gaming category in the HomeShield interface. Access QoS settings through the browser admin panel at 192.168.68.1 under HomeShield > QoS; the browser panel exposes per-device bandwidth allocation alongside traffic category assignment, providing more control than the Deco mobile app alone.

Enabling HomeShield QoS without configuring the WAN upload bandwidth limit does not restrict competing traffic effectively. Set the WAN upload speed to match your ISP plan capacity under the bandwidth settings section. HomeShield uses the configured WAN values to calculate priority fractions: a device in the Gaming tier receives the highest fraction of available bandwidth when contention occurs. Without accurate WAN bandwidth values, the priority calculation defaults to conservative estimates that may not reflect your actual connection speed.

Verifying QoS effectiveness with the jitter tester

After enabling HomeShield QoS and assigning the test device to the Gaming tier, start a large download and watch jitter under load from another LAN device. With QoS correctly configured, jitter during the competing download should stay below 5 ms. Without QoS (or with incorrect bandwidth values), the same download raises jitter to 20 to 50 ms. This before-and-after comparison confirms whether the HomeShield QoS configuration is protecting real-time traffic from competing bulk transfers on the Deco BE63.

IPv6 setup on the Deco BE63 for NAT bypass

IPv6 on the Deco BE63 is available through both the Deco app and the browser admin panel at 192.168.68.1. Navigate to Advanced > IPv6 in the browser admin panel to configure IPv6 address acquisition. The Deco BE63 supports three IPv6 modes: Native (DHCPv6 prefix delegation from the ISP to the Deco, the correct mode for most ISPs), Pass-Through (used when the ISP provides a delegated prefix directly to a specific customer-premises device), and 6to4 Tunnel (a fallback for IPv4-only ISPs). For WebRTC P2P improvement, Native mode is the correct configuration when your ISP provides IPv6.

When IPv6 is active with valid global prefix delegation, devices on the Deco network receive global IPv6 addresses via SLAAC or DHCPv6. WebRTC ICE gathers host candidates from these addresses, which carry higher priority than server-reflexive IPv4 candidates and bypass NAT traversal entirely.⁶ The browser admin panel shows the active IPv6 prefix and assigned addresses under Network > IPv6 Status, confirming whether prefix delegation from the ISP succeeded. If the status shows no prefix, the ISP is not providing IPv6 through the configured mode and the STUN probe will continue using IPv4 candidates.

Confirming IPv6 candidate generation in the browser console

After enabling IPv6 on the Deco BE63, open the browser developer console before starting a P2P test session. ICE candidates generated during connection appear as RTCPeerConnection icecandidate events logged in the console. Filter the console for "candidate" entries; global IPv6 host candidates appear with addresses in the 2001:xxxx format rather than the fe80:: link-local format. Seeing global IPv6 host candidates confirms the Deco BE63 is providing valid global IPv6 addresses and that WebRTC connections to IPv6-capable peers will bypass NAT traversal.

Amazon eero Pro 7 P2P Network Test

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³

No NAT mode setting and UPnP mappings that silently fail

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.

Static port forwarding rules in the eero app

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.

Telling a UPnP failure from upstream symmetric NAT

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.

Under 2 ms on the primary node, 8 to 12 ms on a satellite

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.