TP-Link Archer BE900 P2P Network Test

TP-Link Archer BE900 P2P Test: WebRTC NAT and Gaming Port Check

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¹

NAT type and UPnP on the Archer BE900

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.

WebRTC and P2P configuration on the BE900

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.

Testing the BE900 with this tool

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.