Easy to DoS?

[kchiem]

Describe the bug

I had a tunnel where requests through it were very slow and timing out at times. Noticed a bunch of these errors on the server side rathole instance:

2024-01-18T12:16:37.565691Z ERROR rathole::server: Failed to do transport handshake: Failed to do noise handshake: IO error: Connection reset by peer (os error 104): Connection reset by peer (os error 104)                                   
2024-01-18T12:16:37.565910Z ERROR rathole::server: Failed to do transport handshake: Failed to do noise handshake: IO error: early eof: early eof     

Changed the port the server was listening on and the errors and problems went away. It seems just a little bit of unauthorized traffic to the rathole server port was enough to really mess up performance.

To Reproduce
Steps to reproduce the behavior:

1. establish tunnel
2. hit the bind_addr on the server with random traffic

Configuration
Configuration used to reproduce the behavior:

server.toml:

bind_addr = "0.0.0.0:1234"

[server.transport]
type = "noise"

[server.transport.noise]
local_private_key = "<priv key>"

[server.services.service]
token = "<token>"
bind_addr = "0.0.0.0:2345"

client.toml:

[client]
remote_addr = "host:1234"

[client.transport]
type = "noise"

[client.transport.noise]
remote_public_key = "<public key>"

[client.services.service]
token = "<token>"
local_addr = "127.0.0.1:3456"

Logs
Posted above.

Environment:

• OS: Debian 9.13 on the server, Debian 12 on the client
• rathole --version output: Build Version: 0.5.0 on both
• CPU architecture: x86_64

[fernvenue]

I suggest testing your application on the client side without rathole, it seems that your application is actively refusing the connection.

[kchiem]

I did that. Spent a few hours trying other things before I got down to trying a different server port for rathole. Then the rathole errors went away and the application being tunneled was responsive again.