[Feature]: UDP Full Cone NAT

[qnnnnez]

Platform

Windows

ProxyBridge Version

v3.2.0

OS and Version

Windows 11

Documentation

• I have read the Windows documentation
• I have read the macOS documentation
• I have read the Linux documentation

Code Review

• I have gone through the code page

Describe the Feature

Problem:
For online games that require direct P2P connections, achieving an "Open NAT" (UDP Full Cone NAT) is crucial. The local client must be able to receive UDP connections from various external peers.

After reviewing the C source code of Windows version, I noticed that in the packet processor thread for inbound UDP relay responses, the code unconditionally overwrites the source address of all incoming UDP packets to match the very first destination the local app communicated with:

if (get_connection(dst_port, &orig_dest_ip, &orig_dest_port)) {
    // Restore both source IP and port to original destination
    ip_header->SrcAddr = orig_dest_ip;
    udp_header->SrcPort = htons(orig_dest_port);
}

This essentially implements a Symmetric NAT, and will prevent other remote peers from connecting to the local client.

Proposed solution:
A configuration toggle (e.g., udp_nat_type: "FullCone" | "Symmetric") to control the local NAT behavior.

When FullCone is enabled, instead of restoring the source IP strictly from the orig_dest_ip cached in get_connection(), the UDP relay logic (which reads the inbound SOCKS5 UDP header) should directly use the actual peer IP and Port provided in the SOCKS5 response header to construct the inbound IP packet for WinDivert injection. This bypasses the static table lookup and preserves true peer identity. (If Symmetric is selected, the current orig_dest_ip table lookup logic can be retained for security).

Benefits:
More use cases like online gaming, voice meeting, BitTorrenting, Ethereum node operating.

Additional Context

Related projects for reference:
netch is doing the same thing, but it is not maintained anymore.
xray is a proxy platform. I have used this together with netch for P2P online gaming. It provides good socks5 server implementation, and is good enough for gaming purpose.
hev-socks5-tunnel is a TUN-based proxy solution, but it implements correct Full-Cone UDP NAT, so we can mimic its IP-port matching behavior.

[Anof-cyber]

This is invalid. The connection and the code you mention for the relay server. Proxybridge only looks at outgoing traffic and changes based on the relay server only.

rewrites the source address of all incoming UDP packets

This is only happening within the relay server, meaning all traffic of the relay server only, not for all device traffic. You can look at the architecture of the app in the Windows readme file

[qnnnnez]

Hi, thanks for the quick reply! Let me clarify my point, as I completely agree that ProxyBridge only intercepts the designated LOCAL_UDP_RELAY_PORT traffic.

My issue is specifically about the source address rewriting on inbound traffic sent back to the proxied application.

In a standard P2P gaming scenario:

1. The client sends a UDP packet to the game server.
2. The server shares the client's public (IP, Port) with other peers for direct connection.
3. Peers send UDP packets to this (IP, Port).

The problem is that ProxyBridge delivers these incoming peer packets to the local client with their source addresses overwritten to (orig_dest_ip, orig_dest_port).

Because the local client sees the game server's IP instead of the actual peers' IPs, it cannot correctly identify the peers, which causes the P2P handshake to fail.

[Anof-cyber]

It makes sense, I missed that part. The solution you mentioned cannot be implemented with the current architecture. Although your check is invalid because src and dest IP checks are still required, and with the current method, packets coming from the peer will be dropped since they never match the connection.

I need to verify an alternative. Thanks; this also answers - #166