Port 3479: STUN Alternate — The Shadow Port That Tests Your NAT

Port 3479 is officially registered with IANA as "twrpc" (2Wire RPC), but in practice it serves a more ubiquitous purpose: it is the alternate port for STUN (Session Traversal Utilities for NAT) servers, enabling NAT behavior discovery for billions of video calls, online games, and peer-to-peer connections.

Every time you join a video call, your device runs a quiet experiment. It sends packets to a STUN server on port 3478 and waits to see if the server's response from port 3479 makes it back. If it does, you might be able to talk directly to another person. If it does not, your call will need a relay. Port 3479 is part of the probe.

What Port 3479 Does

Port 3479 serves as the alternate port in STUN server configurations, working alongside the primary port 3478. This dual-port setup enables NAT Behavior Discovery, a technique defined in RFC 5780¹ that determines how your router handles incoming traffic.

When a STUN server receives a request, it can respond from four different address/port combinations:

• Primary IP, Primary Port (e.g., 1.1.1.1:3478)
• Primary IP, Alternate Port (e.g., 1.1.1.1:3479)
• Alternate IP, Primary Port (e.g., 2.2.2.2:3478)
• Alternate IP, Alternate Port (e.g., 2.2.2.2:3479)

By sending responses from port 3479 instead of the expected 3478, the STUN server tests whether your NAT will accept replies from a different port than the one originally contacted. This reveals your NAT's "filtering behavior," which determines whether direct peer-to-peer connections are possible.

The Science of NAT Behavior Discovery

When you are behind a NAT router, you do not have a public IP address. Your router translates between your private address and the public Internet. But NAT devices vary wildly in how they handle this translation, and understanding the exact behavior is crucial for peer-to-peer communication.

RFC 5780 defines a systematic approach:

1. Mapping Behavior Test: Does your NAT assign the same external port when talking to different destinations?
2. Filtering Behavior Test: Will your NAT accept incoming packets from unexpected sources?

Port 3479 is central to the filtering test. If your device sends a request to 1.1.1.1:3478 and successfully receives a response from 1.1.1.1:3479, your NAT has "Endpoint-Independent Filtering." This is the permissive configuration that allows direct peer-to-peer connections.

If the response from port 3479 is blocked, your NAT has stricter filtering, and you will likely need a TURN relay server for real-time communication.

The History: Solving the NAT Problem

The NAT traversal problem emerged in the late 1990s as IPv4 address exhaustion drove widespread NAT deployment. What seemed like an elegant solution for address conservation created a fundamental problem: computers behind NAT could initiate outbound connections, but could not receive unexpected inbound ones.

For VoIP (Voice over IP), this was catastrophic. A phone call requires two-way audio streaming on dynamically allocated ports. NAT devices would routinely break calls, causing one-way audio or complete connection failures.²

Jonathan Rosenberg, working at dynamicsoft and later Cisco, was one of the pioneers who tackled this problem. In 2001-2002, he and colleagues developed the initial STUN specification, published as RFC 3489 in March 2003.³ The original protocol was called "Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators."

The key insight was elegant: if you cannot know your public address, ask someone who can see it. A STUN server sits on the public Internet. You send it a packet, and it tells you the IP address and port from which that packet appeared to originate. Armed with this knowledge, you can share your "reflexive transport address" with a peer.

The Evolution: From Classic STUN to RFC 5780

Classic STUN (RFC 3489) tried to be a complete NAT traversal solution, but it failed. Real-world NAT devices did not fit neatly into the four types the specification defined. The NAT classification algorithm was unreliable, and the protocol had fundamental security vulnerabilities.⁴

RFC 5389, published in October 2008, reimagined STUN as a tool rather than a solution. The acronym was reinterpreted as "Session Traversal Utilities for NAT," acknowledging that STUN works best as part of a larger framework like ICE (Interactive Connectivity Establishment).

RFC 5780, published in May 2010 by Derek MacDonald and Bruce Lowekamp of Skype¹, added the NAT Behavior Discovery extensions. This is where port 3479 gained its formal role as the alternate port, enabling the filtering behavior tests that determine if direct connections are possible.

How the Alternate Port Test Works

Here is what happens when your browser starts a WebRTC video call:

1. Your device sends a STUN Binding Request to the server at 1.1.1.1:3478
2. The server receives your request and sees your public IP:port (say, 203.0.113.50:32768)
3. The server sends back a response containing this address (the XOR-MAPPED-ADDRESS)
4. Your device now knows its "reflexive address"

For filtering behavior discovery, the process adds a twist:

1. Your device sends a request to 1.1.1.1:3478 with a CHANGE-REQUEST attribute asking for "change port"
2. The server responds from 1.1.1.1:3479 instead of 3478
3. If your device receives this response, your NAT has permissive filtering
4. If the response is blocked, your NAT is restrictive and will likely require a TURN relay

Security Considerations

STUN servers, including those using port 3479, can be abused for DDoS amplification attacks. Attackers send requests with spoofed source addresses, causing STUN servers to flood victims with responses. Observed attacks have reached bandwidths of 15-60 Gbps for single-vector attacks, and up to 2 Tbps in multi-vector campaigns that include STUN as a component.⁵

The amplification ratio is relatively modest (approximately 2.32:1), making STUN less attractive than other UDP protocols for amplification. However, the ubiquity of STUN servers makes them appealing targets for attackers building multi-vector attacks.

To mitigate this risk:

• Run STUN over TCP when possible (TCP requires handshake completion, preventing spoofing)
• Implement rate limiting on STUN servers
• Use network-level filtering to prevent spoofed source addresses (BCP38)

The IANA Registration Conflict

Port 3479 presents an interesting case study in port assignment reality versus registry. IANA officially assigned port 3479 to "twrpc" (2Wire RPC) in April 2002, used by 2Wire/Pace home gateways for device management and diagnostics.⁶

However, the port is far more commonly used as the STUN alternate port. This is not a conflict in the technical sense. STUN servers can run on any port, and RFC 5780 simply chose 3479 as the conventional alternate port (primary port + 1). Most STUN implementations default to this configuration.

PlayStation Network uses ports 3478, 3479, and 3480 for NAT traversal during online gaming.⁷ When gamers troubleshoot "NAT Type 3" issues, they are often told to port-forward these three ports. Port 3479 is specifically used for TURN relay services in the PlayStation ecosystem.

Where Port 3479 Lives Today

Port 3479 carries traffic for:

• WebRTC: Every browser-based video call uses ICE, which relies on STUN for candidate gathering. Port 3479 participates in NAT behavior discovery.
• Gaming: PlayStation, Xbox, and countless online games use STUN/TURN for peer-to-peer connectivity. Ports 3478-3480 are standard.
• VoIP: SIP-based phone systems use STUN to discover public addresses for RTP media streams.
• Enterprise Communications: Microsoft Teams, Zoom, and other platforms rely on STUN for direct media connections.

Related Ports