With the increasing demand for proxying P2P traffic using L7 proxy software, there is also a growing need to implement Full Cone NAT in proxy software. This article will briefly analyze NAT behaviors and implementation ins V2Ray.

Definition of NAT Behavior

Currently, NAT behavior is defined by RFC 5780. NAT behavior is divided into two categories: Mapping Behavior and Filtering Behavior.

NAT Mapping Behaviors

Mapping behavior determines the creation and reuse of ports when internal data is sent externally.

• Endpoint-Independent Mapping: Data packets from the same internal address and port are mapped to the same address.
• Address-Dependent Mapping: Data packets from the same internal address and port with the same destination address are mapped to the same address.
• Address and Port-Dependent Mapping: Data packets from the same internal address and port with the same destination address and port are mapped to the same address.

NAT Filtering Behaviors

Filtering behavior determines whether packets are forwarded internally.

• Endpoint-Independent Filtering: All packets from external sources are forwarded internally.
• Address-Dependent Filtering: Packets from the same external address are forwarded internally; others are discarded.
• Address and Port-Dependent Filtering: Packets from the same external address and port are forwarded internally; others are discarded.

Correspondence with RFC 3489

So, what is Full Cone? In fact, the four NAT behaviors, including Full Cone, are defined in RFC 3489. They have the following relationship with NAT behavior in RFC 5780.

V2Ray’s NAT Behavior

As proxy software needs to forward received data externally, it exhibits behavior similar to NAT.

Mapping Behavior

Address and Port-Dependent (Split)

Address and Port-Dependent Mapping is V2Ray’s default NAT behavior. V2Ray will split traffic based on the destination address and port, thereby directing packets of different targets to different outbound connections.

This design is reflected in the VMess and Mux.Cool protocols. For these protocols, each connection transmits only one target address and port in the header, followed by transmitting the payload destined for that address.

Endpoint-Independent (Packet Addr)

In v5.0.2, V2Ray introduced a feature called Packet Addr, which is a “magic” feature implementing Endpoint-Independent Mapping.

Since V2Ray’s transport.Link does not support passing the target address and port, and V2Ray’s code is abstract and complex, implementing Endpoint-Independent Mapping in V2Ray is not straightforward. Packet Addr encodes the target address and port and attaches them to the byte slice originally used for storing UDP payload. The target address is set to sp.packet-addr.v2fly.arpa, achieving routing different packets to the same outbound connection with minimal modifications.

For protocols like Socks 5 and Shadowsocks, V2Ray decodes and encodes the standard UDP format into Packet Addr during inbound processing. During outbound processing, V2Ray decodes Packet Addr and encodes it into the standard format for transmission.

For protocols like VMess, where a single connection cannot transmit packets to different targets, V2Ray directly sends the encoded Packet Addr data as UDP payload during outbound processing, and no decoding is performed during inbound processing.

Finally, Packet Addr is decoded in the freedom outbound, and freedom outbound sends the UDP payload to the target.

Incoming data during outbound is similarly encoded and transmitted to inbound.

Filtering Behaviors

V2Ray’s freedom outbound does not filter packets, so V2Ray’s filtering behavior is Endpoint-Independent Filtering.

Usage of Packet Addr

To use Packet Addr in V2Ray, you need a version equal to or above v5.0.2. If using VMess inbound, no modification to the configuration is needed. For protocols like Socks 5 and Shadowsocks, you need to use the JsonV5 configuration file format and set packetEncoding to Packet in the inbound configuration. Here is an example configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

{
    "inbounds": [
        {
            "protocol": "socks",
            "listen": "127.0.0.1",
            "settings": {
                "udpEnabled": true,
                "packetEncoding": "Packet"
            },
            "port": 1080
        },
        {
            "protocol": "vmess",
            "settings": {
                "users": [
                    "00000000-0000-0000-0000-000000000000"
                ]
            },
            "port": 0
        }
    ],
    "outbounds": [
        {
            "protocol": "vmess",
            "settings": {
                "address": "v2fly.org",
                "port": 0,
                "uuid": "00000000-0000-0000-0000-000000000000"
            }
        }
    ]
}