UDP Support

[pufferffish]

Currently wireproxy doesn't have UDP support at all. There is no support for UDP Associate in SOCKS5, and UDP tunnels have not been implemented.

Challenges:

• While a lot of existing socks5 server implementation supports UDP ASSOCIATE, actual applications that uses UDP ASSOCIATE is extremely rare. Without an established application that uses UDP ASSOCIATE, I cannot confidently test the feature in wireproxy.

• UDP tunnels need to be implemented carefully. UDP itself is stateless so we would need to keep state of which UDP addresses correlate to which UDP connection. Measures also have to be taken to prevent exhausting UDP sockets file descriptors in case of a flood of incoming UDP packets from different IPs.

[PoneyClairDeLune]

Will HTTP/3 implementations in browsers use UDP ASSOCIATE? And is WireProxy going to support FullCone (endpoint independent NAT mapping and filtering, RFC 4787)?

[pufferffish]

Will HTTP/3 implementations in browsers use UDP ASSOCIATE?

This depends on what browser or what proxy plugin you're using on your browser. I haven't investigated this so I'll have to give it a look.

And is WireProxy going to support FullCone (endpoint independent NAT mapping and filtering, RFC 4787)?

Part of the challenge in supporting UDP proxying is picking a proper NAT mapping. Full-cone NAT is the easiest to implement so I might pick this one, but at the same time it can quickly exhaust ports if there are a lot of proxied UDP traffic from different ports. I think I'll implement full cone NAT first, see how it works out, and implement other NAT types if it proves to be insufficient.

[PoneyClairDeLune]

Will HTTP/3 implementations in browsers use UDP ASSOCIATE?

This depends on what browser or what proxy plugin you're using on your browser. I haven't investigated this so I'll have to give it a look.

And is WireProxy going to support FullCone (endpoint independent NAT mapping and filtering, RFC 4787)?

Part of the challenge in supporting UDP proxying is picking a proper NAT mapping. Full-cone NAT is the easiest to implement so I might pick this one, but at the same time it can quickly exhaust ports if there are a lot of proxied UDP traffic from different ports. I think I'll implement full cone NAT first, see how it works out, and implement other NAT types if it proves to be insufficient.

And... When will UDP support arrive?

[JJRcop]

A mainstream program qBitTorrent supports µTP, which is a UDP based torrent protocol. You can set it to only accept µTP connections through connection settings, and try downloading something popular like Ubuntu.

Right now with wireproxy, setting it to µTP only with the SOCKS5 proxy set up stalls all torrents forever, it's a great way to test.

[JJRcop]

Related: #37

[EasyLim]

Today Discord was blocked in Russia.

I tried to use your project to make a local proxy and selectively send traffic through wireguard (make some of the traffic go through wireguard, and the other part as usual) using PAC script. And everything works successfully, all sites work, but Discord voice chats don't work. I suspect this is because you don't have UDP support, so I'd like to see UDP support as soon as possible.

Maybe there are some other solutions, how can I selectively route traffic through wireguard?

[ge9]

Wireproxy currently uses things-go/go-socks5 as a SOCKS5 library. It supports UDP associate, but it replies wrong address for UDP associate request (things-go/go-socks5#64). I and another user proposed different fixes, but neither is merged for now.
I tested wireproxy with my fork of go-socks5 and it worked.
Actually, hoever, some SOCKS5 transparent proxy clients (including https://github.com/wiresock/proxifyre and https://github.com/heiher/hev-socks5-tproxy) cares only the port (not address), so they work correctly with current go-socks5 (and thus wireproxy).