Indy's Zero UDP ASSOCIATE Address Is Not the Datagram Target

Separate the client association address, returned SOCKS relay and target encoded into each UDP packet.

0.0.0.0:0 in an Indy UDP ASSOCIATE request can be intentional. That request describes the expected client-side UDP endpoint, and RFC 1928 permits zeros when it is unknown. It does not select the final service.

The reply's BND.ADDR/BND.PORT identifies the relay to which the client sends encapsulated datagrams.

TCP control: client → SOCKS5 proxy → UDP association reply
UDP payload: client → returned relay address → target service

In Indy, TIdUDPClient.Connect calls the transparent proxy's OpenUDP. TIdSocksInfo supplies the zero association fields. Later, SendBuffer passes the desired service to SendToUDP, which builds the SOCKS UDP destination header before the application payload.

If association succeeds but traffic fails, inspect the returned relay, encoded destination and UDP reply path. NAT/firewalls can admit the TCP exchange while blocking UDP.

Keep the TCP control connection open; closing it ends the association. SOCKS4/4a lack this operation, and SOCKS5 branding alone does not guarantee that a server supports UDP.

Artiglyn mynjee