TCP connection on TUN interface can not be terminated properly

[Keith-amateur]

my locals configuraion

"locals": [
		{
			"protocol": "redir",
			"local_address": "127.0.0.1",
			"local_port": 10080,
			"tcp_redir": "redirect",
			"mode": "tcp_only"
		},
		{
			"protocol": "tunnel",
			"local_address": "127.0.0.1",
			"local_port": 5353,
			"forward_address": "8.8.8.8",
			"forward_port": 53,
			"mode": "tcp_and_udp"
		},
		{
			"protocol": "tun",
			"tun_interface_name": "tun0",
			"tun_interface_address": "10.255.0.10/24",
			"mode": "tcp_and_udp"
		}
	]

I'm using the latest version of sslocal(v1.15.3) and my operating system is Arch Linux with kernel 6.2.2.

"curl --interface tun0 ip.gs"

I usually use the above command to check which server is the current outbound. The http response is correct.
However, there are a lot of TCP Retransmissions after the request.

It seems that the second FIN can't get ack. And sslocal seems to neglect the TCP RST which is sended by br0.(the interface access to the Internet). It doesn't interfere my daliy use. I am just a little curious.

[zonyitoo]

The IP in your screenshot 185.222.217.207 is your ssserver? So the main problem is that FIN,ACK sent from ssserver didn't get respond properly.

Since the TCP connection between sslocal and ssserver is using standard socket APIs, which is maintained by the kernel. Could you try with another frontends, such as SOCKS5, Tunnel, ... and see if the problem still exists.

[Keith-amateur]

The IP in your screenshot 185.222.217.207 is your ssserver? So the main problem is that FIN,ACK sent from ssserver didn't get respond properly.

Since the TCP connection between sslocal and ssserver is using standard socket APIs, which is maintained by the kernel. Could you try with another frontends, such as SOCKS5, Tunnel, ... and see if the problem still exists.

Well, 185.222.217.207 is the IP of ip.gs, not my ssserver.
ip.gs is a website that returns the current IP that I am using to get access to the Internet. Since I have multiple ssservers, I use curl --interface tun0 ip.gs to see which one sslocal is currently using.

In my understanding, after I typed curl --interface tun0 ip.gs, the network traffic goes like below.

1. kernel generates SYN with dst addr 185.222.217.207 and use tun0 to send it.
2. sslocal reads SYN from tun0 and finishes the 3-way handshake.
3. sslocal reads the application data(in this case, http request) from tun0, packs it into a shadowsocks request and sends it to one of my ssservers using br0.(based on my policy routing)
4. my ssserver forwards the http request to 185.222.217.207 and returns the response(in this case, response data is the IP of my ssserver) to sslocal.
5. sslocal writes the response data into tun0, kernel reads it and show it on my terminal.
   After the request is finished, kernel needs to terminate the tcp connection. My Problem happens in the following parts
6. kernel sends the first FIN,ACK and gets ACK properly from sslocal.
7. sslocal sends the second FIN,ACK and kernel sends RST using br0 instead of sending ACK using tun0. (This confuses me most)
8. sslocal can't get ACK properly, so it keeps resending FIN,ACK. (like in the screenshot above)

So, I guess there may be some problems when sslocal processes the 4-way handshake of termination on tun0.

[Keith-amateur]

Sorry. As it turned out, I was using shadowsocks 1.15.0-alpha.9 last night. I replaced the binary file and restarted systemd. It didn't work...still using the old version.(systemd works in a mysterious way...)
Anyway, I tried the binary file(shadowsocks 1.15.2) from release this morning. The phenomenon was the same.

[zonyitoo]

Well, I think the key issue is "kernel sends RST using br0". Why?

Could you see any problems in the FIN,ACK sending from sslocal?

[Keith-amateur]

The sequence number of tcp segments from sslocal seems not to start at a random number. Besides that I didn't see any problems.

[zonyitoo]

Couldn't reproduce on my OpenWRT router with Kernel 5.4.188. I couldn't capture any retransmissions on tun0.

baidu.pcap.zip

[Keith-amateur]

Couldn't reproduce on my OpenWRT router with Kernel 5.4.188. I couldn't capture any retransmissions on tun0.

baidu.pcap.zip

I have tried curl --interface tun0 https://www.baidu.com. There weren't any retransmissions on my PC either. And the FIN,ACK from sslocal was pretty fast. In the above screenshot, I have to wait for a while before retransmissions appear.

I have tried the following commands one by one. The reponse data are all correct.

curl --interface tun0 https://www.baidu.com
curl --interface tun0 http://www.baidu.com
curl --interface tun0 https://www.google.com

only showing the FIN,ACK and the RST.
Please pay attention to the time interval between the corresponding FIN,ACK.

https://www.baidu.com was ideal.
http://www.baidu.com took a rather long time to finally send the FIN,ACK.
https://www.google.com obviously didn't terminate the connection properly.
I am wondering how sslocal decides when to send FIN,ACK. And Why does it behave so differently?
traffic-tun0.tar.gz

[zonyitoo]

Please try and see if the latest commit helps.

Ah, I could reproduce it locally!

[zonyitoo]

I believe this commit should fix this issue, please test the latest nightly build.

[Keith-amateur]

Thank you so much for your consistent help!

[Keith-amateur]

I believe this commit should fix this issue, please test the latest nightly build.

You nailed it! Now it works perfectly!