how do you limit access to the udp association if the client is in a LAN?

[Danieldachao]

In RFC 1928, it says:

The DST.ADDR and DST.PORT fields contain the address and port that the client expects to use to send UDP datagrams on for the association. The server MAY use this information to limit access to the association.

But if the client is in a LAN, the server would get a totally different addr and port when receiving udp packets because of the NAT.Then how could i limit access to the udp association?

[txthinking]

Thx, I am working on this function. Server before handle udp packet, it should check the src if prepared by a tcp connection

[txthinking]

This is nothing about LAN or WLAN, it just care DST.ADDR and DST.PORT.

Before send UDP data, client send DST.ADDR and DST.PORT with a TCP connection, so we can store DST.ADDR and DST.PORT and compare it with src of UDP when UDP data come.

But If server get zero:zero DST.ADDR and DST.PORT with a TCP connection, how to limit or compare it with src of UDP when UDP data come. https://stackoverflow.com/questions/62283351/how-to-use-socks-5-proxy-with-tidudpclient-properly This link said:

If the requested Host/Port is all zeros, the relay should simply use the Host/Port that sent the request. That means server should assume DST.ADDR and DST.PORT is src of TCP? [a]

this[a] is what I did, but looks like some software don't do with this. like proxycap do:

proxycap(src1) -- tcp --zero DST.ADDR and DST.PORT--> socks5 server
proxycap(src2) -- udp --socks5 server

If the stackoverflow link is correct, src2 should equal with src1

[Danieldachao]

Yes, DST.ADDR and DST.PORT matter. But if the client is in a lan, it does not have a public ip. When it wants to negotiate with the server, it can only fill local ip and port into DST.ADDR and DST.PORT. After negotiation, when udp packets come, the server would get a public ip which is mapped by a NAT device like a Router instead of the local ip which the client filled in during the negotiation. So I still can not compare those 2 address. Does this make sense? Or in this situation, the client should use zero:zero DST.ADDR and DST.PORT ?

[txthinking]

https://github.com/txthinking/socks5/blob/master/server.go#L43

If set LimitUDP with true, server will check incoming src if it has been sent by a prev tcp connection

[txthinking]

Yes, DST.ADDR and DST.PORT matter. But if the client is in a lan, it does not have a public ip. When it wants to negotiate with the server, it can only fill local ip and port into DST.ADDR and DST.PORT. After negotiation, when udp packets come, the server would get a public ip

Yes, this is NAT's work. socks5 server only can handle incoming src, https://en.wikipedia.org/wiki/Network_address_translation

And more, socks5 server is also a NAT too, this library implements Symmetric NAT

[hayden-pan]

Yes, DST.ADDR and DST.PORT matter. But if the client is in a lan, it does not have a public ip. When it wants to negotiate with the server, it can only fill local ip and port into DST.ADDR and DST.PORT. After negotiation, when udp packets come, the server would get a public ip

Yes, this is NAT's work. socks5 server only can handle incoming src, https://en.wikipedia.org/wiki/Network_address_translation

And more, socks5 server is also a NAT too, this library implements Symmetric NAT

The situation mentioned by @Danieldachao just like this: Application Client - SOCKS Client - NAT - SOCKS Server - Application Server Then the SOCKS Client can only set the UDP Association DST.ADDR and DST.PORT with zero because can not foresee the NAT's behavior. There is no problem. The problem is how SOCKS Server relate a incoming udp packet with current tcp connection when a lot of SOCKS Clients request the UDP Association command concurrent ?

After my deep thinking, we can set the reply of UDP Association command with a dynamic BND.PORT to solve. Then SOCKS Server can relate the incoming udp packet with a TCP connection correct.

[txthinking]

Server.LimitUDP