UDP relay implementation does not honor SOCK5 RFC

[siwliu-kernel]

A openvpn client has the following config in /etc/openvpn/client/client.conf:

remote 111.111.111.111 1194 udp
route 111.111.111.111 255.255.255.255 10.0.0.1
socks-proxy 127.0.0.1 1080

Launch this openvpn client over SSRoT ends up with below error:

# openvpn --suppress-timestamps --nobind --config /etc/openvpn/client/client.conf
:
:
TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:1080
Attempting to establish TCP connection with [AF_INET]127.0.0.1:1080 [nonblock]
TCP connection established with [AF_INET]127.0.0.1:1080
UDP link local: (not bound)
UDP link remote: [AF_INET]111.111.111.111:1194
TCP/UDP: Incoming packet rejected from [AF_INET]127.0.0.1:57477[2], expected peer address: [AF_INET]111.111.111.111:1194 (allow this incoming source address/port by removing --remote or adding --float)
TCP/UDP: Incoming packet rejected from [AF_INET]127.0.0.1:57477[2], expected peer address: [AF_INET]111.111.111.111:1194 (allow this incoming source address/port by removing --remote or adding --float)

UDP socket 127.0.0.1:57477 was opened by openvpn client to get the response from openvpn server 111.111.111.111:1194 through ssr-client's udp relay:

Jan 1 00:00:51 hostname ssr-client[6122]: #33[0mssr-client 2023/01/01 00:00 info #33[0m[udp] 127.0.0.1:57477 ==> 111.111.111.111:1194 incoming data from lower-level app, length = 24
Jan 1 00:00:51 hostname ssr-client[6122]: #33[0mssr-client 2023/01/01 00:00 info #33[0m[udp] 127.0.0.1:57477 <== 111.111.111.111:1194 write back received data length = 26
Jan 1 00:00:51 hostname ssr-client[6122]: #33[0mssr-client 2023/01/01 00:01 info #33[0m[udp] 127.0.0.1:57477 ==> 111.111.111.111:1194 incoming data from lower-level app, length = 24
Jan 1 00:00:51 hostname ssr-client[6122]: #33[0mssr-client 2023/01/01 00:01 info #33[0m[udp] 127.0.0.1:57477 <== 111.111.111.111:1194 write back received data length = 22

The error reported by openvpn is because udp_relay_send_data() doesn't fill target_addr to the DST.ADDR field (techinicallly it would be the source address for the original UDP packet where ssr-server had gotten in the first place) in udp relay header per the SOCKS5 RFC spec.

shadowsocksr-native/src/client/client.c

Lines 1481 to 1491 in 81a9545

	p = buffer_get_data(tmp);
	s = buffer_get_length(tmp);
	udp_relay_send_data(ctx->udp_data_ctx->udp_ctx, &ctx->udp_data_ctx->src_addr, p, s);
	{
	char* src = universal_address_to_string(&ctx->udp_data_ctx->src_addr, &malloc, true);
	char* tmp = socks5_address_to_string(&ctx->udp_data_ctx->target_addr, &malloc, true);
	pr_info("[udp] %s <== %s write back received data length = %ld", src, tmp, (long)s);
	free(tmp);
	free(src);
	}

target_addr can be passed in udp_relay_send_data() to replace s5addr:

shadowsocksr-native/src/udprelay.c

Line 600 in b39d0cf

dup_data = s5_build_udp_datagram(&s5addr, data, len, &malloc, &len);

uv_udp_send() should still use src_addr as is:

shadowsocksr-native/src/udprelay.c

Line 605 in b39d0cf

uv_udp_send(send_req, &udp_ctx->udp, &sndbuf, 1, &addr->addr, udp_relay_sent_cb);

[siwliu-kernel]

I've verified that openvpn works back fine after changing the above lines of code as indicated. I haven't checked if the other client for e.g. Windows, iOS or Android has similar issue. I'd leave it to @ssrlive to decide.

The ideal solution is to get the corresponding source address for the UDP response packet from the ssr-server, though. A target server could be multi-homed that the UDP response packet may not neccessarily come from the orginal IP address the UDP request was sent to.

[ssrlive]

Yes. but I have no plan to correct the issues. Please play my new toy overtls which support UDP relay very fine.