Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When server closes connection, connection hangs on client (between two wireproxy) #130

Open
leahneukirchen opened this issue Jul 12, 2024 · 0 comments

Comments

@leahneukirchen
Copy link

leahneukirchen commented Jul 12, 2024

Say you connect two Wireproxy instances:

[Interface]
Address = 10.11.11.2/32
PrivateKey = xxx

[Peer]
PublicKey = yyy
Endpoint = zzz:19999

[TCPServerTunnel]
ListenPort = 9100
Target = 127.0.0.1:9100

and

[Interface]
Address = 10.11.11.1/32
PrivateKey = vvv
ListenPort = 19999

[Peer]
PublicKey = www
AllowedIPs = 10.11.11.2/32

[TCPClientTunnel]
BindAddress = 127.0.0.1:9102
Target = 10.11.11.2:9100

Now, run a trivial TCP server on the one side:

ncat -l 9100 --sh-exec "echo hello"

And connect on the other side:

% ncat 127.0.0.1 9102
hello
<HANGS>

I think this happens because the two pattern of running two io.Copy goroutines doesn't notice a connection is closed in both directions? When I patch the goroutines to close conn and sconn after one io.Copy terminates, my use case works. But I'm not sure that is correct when half-open TCP connections are being used.

This probably doesn't occur when one side is a kernel-based WireGuard stack, as then the OS TCP stack will handle the connection closing... [EDIT: also happens when using WireGuard on FreeBSD directly instead of a TCPClientTunnel there.]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant