Behavior of tun2socks with closed TCP ports

[bitsadmin]

First of all, thanks Jason for this great tool!

I have a question regarding the TCP behavior of the tunnel.

I have set up the tunnel over SOCKS4 and added the relevant route over the tun interface. Any TCP ports reachable on the other side work well, however when attempting to connect to a non-existing IP and/or TCP port (sending a SYN packet), the tunnel interface regardless on whether it is reachable immediately responds with a SYN/ACK to the client. Only once it identified that the IP/port are not reachable (RST packet is received or simply no response is received on the SOCKS server end), tun2socks sends a FIN/ACK packet to the client.

This behavior can be confusing for applications attempting to establish TCP connections. In various cases a better behavior would be that the tunnel responds with a SYN/ACK only at the moment it identified that on the other side of the tunnel the port is actually accessible.

Summarized, the behavior I would like to see:

1. Port closed (RST) on remote side -> RST from tunnel to client
2. Port does not respond on remote side -> No response from tunnel to client
3. Port is open (SYN/ACK) on remote side -> SYN/ACK from tunnel to client

I haven't looked at the SOCKS protocol specification, so not sure whether it can distinguish between 1 and 2, but both RST or a timeout would be fine for the client application to realize a connection cannot be established.

Is there a way to have tun2socks work like that?

[xjasonlyu]

Thanks for your feedback!

There's a similar issue #83 (in Chinese). Typically, this behaviour is caused by the user-space network stack, which responds to all incoming connections without checking the validation of target address. By doing this, tun2socks can usually handle connections faster and reduce more hanging/half-open TCPs.

I understand this may cause some issues and agree that we can make some improvements. But on the other hand, think of tun2socks as a CDN, it does almost the same thing (accepts connections and forwards them or responds to failure pages). So it might also be a feature. :-P

[bitsadmin]

Ah, I missed that one, that is indeed very similar. Thanks for reopening that feature! Would be great to provide such behavior as an optional feature using a commandline flag.

Definitely understand the analogy with a CDN, and in many occasions tun2socks is probably also used for that and then it is more performant to just assume the remote endpoint is accessible, and "fix" the connection state later using a FIN/ACK in case it turns out that the port on the remote side was not reachable after all :)

To be able to perform some testing with the alternative behavior I looked into the code to "hack" this feature into it. I however couldn't easily identify what code should be modified. Do you think it would be possible to change this behavior by changing some lines of code (e.g, by swapping the current sequence of 1) accepting the client TCP connection and 2) connecting to the port on the remote side)? Or is it much more of an architectural change.

[xjasonlyu]

To make this happen, the complexity is a bit more than just changing lines of code. If you want to check the validation of your destination connections before accepting incoming TCPs, you should dig into here, right before calling CreateEndpoint:

tun2socks/core/tcp.go

Line 61 in 4a8bf64

ep, err = r.CreateEndpoint(&wq)

However, since tun2socks handles outgoing proxy connections in the tunnel pkg after the core module sends out the TCP conn, you will need to figure out how to call proxy.Dial before getting into tunnel mode.

Anyway, it may take some tricks to implement this and I wish you have a good luck. I’m currently too occupied to add this feature. Please let me know if you have any other questions!

[bitsadmin]

Thanks a lot Jason for this extensive explanation!

I have spent some time understanding the code and performing a number of modifications (changing the sequence of checking whether the remote port is open and only then accepting the connection), however currently my limited golang knowledge and a lack of time to climb the learning curve make that for now I will stop working on it.

Maybe whenever in the future I have more time, I will pick it up again and might get back to you with some questions. 🙂

[0990]

socks5 server proxy return little information when dial remote fail,we can use it,What #235 do is dial proxy before 3handshake,then decide what to do after get dial fail reason,here is detail:

<style> </style>

SOCKS Error Code	Description	Current Process	Pull Request#235	Better Solution?
X'01'	General SOCKS server failure	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	?
X'02'	Connection not allowed by ruleset	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	?
X'03'	Network unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	ICMP notify or no response?
X'04'	Host unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	ICMP notify or no response?
X'05'	Connection refused	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	3handshake fail,return RST(not connect)
X'06'	TTL expired	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	ICMP notify or no response?
X'07'	Command not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	?
X'08'	Address type not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	?
X'09' to X'FF'	Unassigned	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	?

what is better way?(forgive my pool English)

[xjasonlyu]

@bitsadmin Hi there, maybe you wanna provide some advice! :-P

[bitsadmin]

Thanks @0990 for looking into this, and useful to have this table to define the behavior!

I think the following could work well, where in some cases it's just TCP which sends a RST packet or just nothing, and in some cases ICMP is used to indicate what the issue is.

SOCKS Error Code	Description	Current Process	Pull Request#235	Better Solution?
X'01'	General SOCKS server failure	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response
X'02'	Connection not allowed by ruleset	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'03'	Network unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: net unreachable (type 3, code 0)
X'04'	Host unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: host unreachable (type 3, code 1)
X'05'	Connection refused	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'06'	TTL expired	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: TTL expired in transit (type 11, code 0)
X'07'	Command not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response
X'08'	Address type not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response
X'09' to X'FF'	Unassigned	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response

Resources

• Useful table with all ICMP control messages (including type and code): https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Control_messages
• ICMP RFC: https://www.rfc-editor.org/rfc/rfc792 with at page 4 the list of Destination Unreachable Messages

[xjasonlyu]

And, if there's a default response for proxy failure, it would be RST. e.g. HTTP proxy as backend proxy server, since it does not have those return codes like SOCKS5 does.

[xjasonlyu]

@0990 BTW, to send RST in gVisor, just call r.Complete(true).

tun2socks/core/tcp.go

Lines 60 to 67 in 4a8bf64

	// Perform a TCP three-way handshake.
	ep, err = r.CreateEndpoint(&wq)
	if err != nil {
	// RST: prevent potential half-open TCP connection leak.
	r.Complete(true)
	return
	}
	defer r.Complete(false)

[0990]

@bitsadmin thanks for your advice,in my opinion,the default way is RST(tell client imediately insead of waiting long time),So my suggestion:

SOCKS Error Code	Description	Current Process	Pull Request#235	Better Solution?
X'01'	General SOCKS server failure	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'02'	Connection not allowed by ruleset	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'03'	Network unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: net unreachable (type 3, code 0)
X'04'	Host unreachable	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: host unreachable (type 3, code 1)
X'05'	Connection refused	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'06'	TTL expired	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: No response + ICMP: TTL expired in transit (type 11, code 0)
X'07'	Command not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'08'	Address type not supported	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST
X'09' to X'FF'	Unassigned	Socket close immediately (connect already)	3handshake fail,return RST(not connect)	TCP: RST

[bitsadmin]

It gives away a little bit less information on the actual state of the port on the remote host (whether it is refused using TCP RST packet or TCP packet is dropped), however it definitely speeds up things on the client side if after a SYN/ACK a RST packet is received in case the port on the remote host is not reachable.

Such setup with TCP RST responses would work well for me!

[0990]

@xjasonlyu I have commit code:feat:give client no response when socks server return host unreachable,please review when have time.
As to ICMP Notify,It need discussion because "No ICMP response is returned in most cases"(I test several ip:port,maybe I am wrong)

[m2abrams15]

Sort of resurrecting an older thread, but i also was doing some testing with this. Ideally, trying to emulate something more akin to how proxychains connects (establish connection with remote end BEFORE establishing connection).

was using nmap scanning as an example. With proxychains, can proxy a scan and the connection is built to the target before the connection is returned true.

Without proxychains, the connection is established and returned true before it is built with target. Could this behavior be set as a switch? I am NOT a go SME, and reading above, sounds like it would be a bigger shift to do that than i expect.

@bitsadmin was wondering if you had any luck cracking this egg or not

[bitsadmin]

Very late response, but I was busy with various things including publishing a blog article where tun2socks is used[1] to an offensive setup.

I just did some quick tests using your fork[2], @0990, and it works as expected, very nice! 😃 As there might be use cases where this behavior is not desired, like @m2abrams15 mentioned it is probably useful to have a command line flag where the behavior can be chosen. Any chance you could add this to your code? After that, would love to see @xjasonlyu merge your pull request!

[1] https://blog.bitsadmin.com/living-off-the-foreign-land-windows-as-offensive-platform
[2] https://github.com/0990/tun2socks.git