5 ms·

Show HN: connet – A P2P reverse proxy with NAT traversal

130 points by Ingon 2y ago

Over the past couple of months, I've been working on connet. At this point, it is working pretty smoothly (in what I use it for), so I wanted to share it with more people and see what they think. I know many other similar/reverse proxy solutions exist - like https://github.com/fatedier/frp https://github.com/fatedier/frp, https://github.com/rapiz1/rathole https://github.com/rapiz1/rathole, and a bunch more you can find at https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling. However, I wanted to try and put my own little peer-to-peer twist on it. Thanks for checking it out, and sharing any feedback you might have!

rudasn 2y ago
Nice. I really like the config format regarding the services available/exposed. Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?
- Ingon 2y ago
  Thanks for taking a look! Initially, I did think I'll be using wireguard. What stopped me at the time (as far as I remember) was that I couldn't just use the protocol part of the official golang library (e.g. https://git.zx2c4.com/wireguard-go/about/ https://git.zx2c4.com/wireguard-go/about/). Another thought I had at the time, was that I would had to use the user-space wireguard implementation, which everyone claimed was slow (I should have probably looked into how slow it is). Another thought I had was to use the noise protocol (which wiregruard also uses) for security and building on top of that. Which meant I would have to implement most of what QUIC (and wireguard) does to make UDP a reliable protocol - retries, ordering, streams, etc. So, eventually, I just settled on using QUIC for the first version - later we can always add more ways for peers to connect to each other.
  - quie 2y ago
    wireguard does not do any retries, ordering or streams, see the whitepaper and the code which are marvels of engineering.
    - Ingon 2y ago
      thanks for correcting me, its been a while since I've looked at the whitepaper
r3trohack3r 2y ago
This looks great! Have you seen the libp2p project? Might help get you pluggable NAT traversal and transport strategies plus peer discovery. We’ve been using rust-libp2p for building an overlay network and have had decent success.
- Ingon 2y ago
  Thanks! No, I wasn't aware of libp2p. Looks very relevant to what I'm doing, and I'll definitely take a closer look. Thanks for pointing it out!
  - Uptrenda 2y ago
    It ain't, trust me. No one who promotes Libp2p ever knows how it works much like users of all of Protocol Labs products. The average "engineer" today rarely looks deeper than the title of the tech they use. They are just glorified plumbers plumbing together pipes filled with [redacted.] You'll waste your time on Libp2p because it already works almost exactly like your own project. It uses a network of relays as a fallback. It does add in hole punching but no one at Protocol Labs understands how a NAT works. So it only works for a subset of NATs (full cone; restrict; specifically with source port preserving delta behaviours.) Protocol Labs is filled with big egos and midwits. In 2025, I have zero time for bullshitters and I'm going to call them out for it.
    - r3trohack3r 2y ago
      I’m not sure what you’re going on about. The rust-libp2p project has worked really well for me and I’m in the guts of it constantly. Everything has been pluggable in the right ways so far. Adding new behaviors is straightforward. I can plug and play behaviors, or feature flag them, to pump out purpose built binaries. It seems like a solid foundation for p2p research and productionizing that research. When I want to experiment with a new protocol, I can plug it in as a behavior without having to solve the rest of the stack. I have a suspicion that in 2025 imma have to rip open the guts of swarm again to tweak connection management (we are aggressive with connections) but that isn’t daunting. The only gripe I have with rust-libp2p right now is the learning curve (this was my first rust project - which is probably most of it).
crtasm 2y ago
Suggestion for the quickstart: refer to the clients as either D,S or a,b throughout - I found the mixture a bit confusing.
- Ingon 2y ago
  Thanks for checking it out and pointing this inconsistency! I've updated the readme, hopefully it is less confusing now.
valorzard 2y ago
Can I use this to host a Minecraft server? I’ve used hamachi and zero tier in the past, and the former USED to work but stopped recently for some reason
- Ingon 2y ago
  While I haven’t tested it with Minecraft (I was planning to) I believe it should basically work. Let me know how it went if you decide to try it!
hailruda 2y ago
So if I understand correctly, this should be comparable to what Tailscale is doing?
- Ingon 2y ago
  You can achieve a similar effect with both, yes. However, they fundamentally work differently. Tailscale (e.g. wireguard) is a way to create a virtual private network between two (or more) machines. This means they can pretend they are on the same network, even if they are physically on different networks. Now, having them on the same (virtual) network, means you can open up the firewall on the target machine (for that specific network), and access services that are running there. You'll still need to use the other machine's IP address/name on that network to access it. connet on the other hand is more like a projection (or tunnel) - it opens up a TCP listener on your local machine, and internally forwards all connections and traffic to the TCP listener that is running on the remote machine. At your local machine, it looks like you are running the target service locally, and you access it via localhost. I hope this explains how is connet different from Tailscale, thanks for checking it out!
nurettin 2y ago
I have been using autossh in production for the past decade without problems. Does frp/ngrok/connet, etc. have any advantage that I don't know about?
- Ingon 2y ago
  At first I was confused as how autossh was relevant here, since it seemed like a supervisor for the ssh process (from https://github.com/Autossh/autossh https://github.com/Autossh/autossh). Then I realized that you are probably running ssh (reverse) tunnels. If that works for you, I don't think you should change! With others, I think its a mixed bag, in no particular order: * in my experience, opening up new connections in SSH is somewhat slow (compared to QUIC and ngrok). I believe this was due to how SSH verifies each new stream. * connet (and others that use UDP based protocols) don't experience the TCP head of line blocking issue. This might not be an issue necessarily, especially if you have a good, consistent connection between peers. * some of the other tools provide much richer interface (compared to raw SSH), like traffic inspection and modification, different security properties, etc * connet (and others) does allow multiple destinations and sources binding on the same name, so you can have multiple clients talking to a clustered service This is it off the top of my mind. Thanks for checking connet out!
Uptrenda 2y ago
Spent 2 years working on the same problem. Ended up designing a library that does: - direct connect - reverse connect - tcp hole punching - turn support Has other features too like: - multi-interface - duel-stack - port forwarding and pin holes Show some love cause its at 64 stars and is IMO, objectively better for direct peer-to-peer networking than OPs library that only supports direct, reverse, and relay, and which doesn't seem to do anything to open ports or firewalls. It does make me salty that I try so hard with my own work but what seems to make people successful is their ability to get lucky on sites like this or game them. No offense to OP. Here's my project: https://github.com/robertsdotpm/p2pd https://github.com/robertsdotpm/p2pd
- yownie 2y ago
  ≥- duel-stack dual-stack unless they have sabers
  - Uptrenda 2y ago
    Maybe they do, TCP hole punching is like a duel in a way. You are right tho, my spelling is horrible. Hope my message above doesn't come off in bad taste. I should be happy for the OP I guess.
- Ingon 2y ago
  connet is a young project, and draws inspiration from many great projects like yours. Thanks for sharing it, I starred it!
  - Uptrenda 2y ago
    thanks man, sorry if i came off harshly will edit my post tbh, its a bad look. keep working on your project. I do see the need for what you're doing.
    - SupremeQuartz 2y ago
      "Love me overwatch. Love cheese pizza. Love Indian food. Love nature. Love the rain. Love me aul ma. Love me grand parents. Love ...love...love..." there ain't no god damn way, bro
linuxdude314 2y ago
You can do this with SSH alone. https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4e3e34a55d https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4...
- palata 2y ago
  But with SSH you won't get NAT traversal and then the direct connection, right? You will forward through a server. Or am I missing something?

130 points by Ingon 2y ago

rudasn 2y ago

Nice. I really like the config format regarding the services available/exposed. Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?

Ingon 2y ago
Thanks for taking a look! Initially, I did think I'll be using wireguard. What stopped me at the time (as far as I remember) was that I couldn't just use the protocol part of the official golang library (e.g. https://git.zx2c4.com/wireguard-go/about/ https://git.zx2c4.com/wireguard-go/about/). Another thought I had at the time, was that I would had to use the user-space wireguard implementation, which everyone claimed was slow (I should have probably looked into how slow it is). Another thought I had was to use the noise protocol (which wiregruard also uses) for security and building on top of that. Which meant I would have to implement most of what QUIC (and wireguard) does to make UDP a reliable protocol - retries, ordering, streams, etc. So, eventually, I just settled on using QUIC for the first version - later we can always add more ways for peers to connect to each other.
- quie 2y ago
  wireguard does not do any retries, ordering or streams, see the whitepaper and the code which are marvels of engineering.
  - Ingon 2y ago
    thanks for correcting me, its been a while since I've looked at the whitepaper

r3trohack3r 2y ago

This looks great! Have you seen the libp2p project? Might help get you pluggable NAT traversal and transport strategies plus peer discovery. We’ve been using rust-libp2p for building an overlay network and have had decent success.

Ingon 2y ago
Thanks! No, I wasn't aware of libp2p. Looks very relevant to what I'm doing, and I'll definitely take a closer look. Thanks for pointing it out!
- Uptrenda 2y ago
  It ain't, trust me. No one who promotes Libp2p ever knows how it works much like users of all of Protocol Labs products. The average "engineer" today rarely looks deeper than the title of the tech they use. They are just glorified plumbers plumbing together pipes filled with [redacted.] You'll waste your time on Libp2p because it already works almost exactly like your own project. It uses a network of relays as a fallback. It does add in hole punching but no one at Protocol Labs understands how a NAT works. So it only works for a subset of NATs (full cone; restrict; specifically with source port preserving delta behaviours.) Protocol Labs is filled with big egos and midwits. In 2025, I have zero time for bullshitters and I'm going to call them out for it.
  - r3trohack3r 2y ago
    I’m not sure what you’re going on about. The rust-libp2p project has worked really well for me and I’m in the guts of it constantly. Everything has been pluggable in the right ways so far. Adding new behaviors is straightforward. I can plug and play behaviors, or feature flag them, to pump out purpose built binaries. It seems like a solid foundation for p2p research and productionizing that research. When I want to experiment with a new protocol, I can plug it in as a behavior without having to solve the rest of the stack. I have a suspicion that in 2025 imma have to rip open the guts of swarm again to tweak connection management (we are aggressive with connections) but that isn’t daunting. The only gripe I have with rust-libp2p right now is the learning curve (this was my first rust project - which is probably most of it).

crtasm 2y ago

Suggestion for the quickstart: refer to the clients as either D,S or a,b throughout - I found the mixture a bit confusing.

Ingon 2y ago
Thanks for checking it out and pointing this inconsistency! I've updated the readme, hopefully it is less confusing now.

valorzard 2y ago

Can I use this to host a Minecraft server? I’ve used hamachi and zero tier in the past, and the former USED to work but stopped recently for some reason

Ingon 2y ago
While I haven’t tested it with Minecraft (I was planning to) I believe it should basically work. Let me know how it went if you decide to try it!

hailruda 2y ago

So if I understand correctly, this should be comparable to what Tailscale is doing?

Ingon 2y ago
You can achieve a similar effect with both, yes. However, they fundamentally work differently. Tailscale (e.g. wireguard) is a way to create a virtual private network between two (or more) machines. This means they can pretend they are on the same network, even if they are physically on different networks. Now, having them on the same (virtual) network, means you can open up the firewall on the target machine (for that specific network), and access services that are running there. You'll still need to use the other machine's IP address/name on that network to access it. connet on the other hand is more like a projection (or tunnel) - it opens up a TCP listener on your local machine, and internally forwards all connections and traffic to the TCP listener that is running on the remote machine. At your local machine, it looks like you are running the target service locally, and you access it via localhost. I hope this explains how is connet different from Tailscale, thanks for checking it out!

nurettin 2y ago

I have been using autossh in production for the past decade without problems. Does frp/ngrok/connet, etc. have any advantage that I don't know about?

Ingon 2y ago
At first I was confused as how autossh was relevant here, since it seemed like a supervisor for the ssh process (from https://github.com/Autossh/autossh https://github.com/Autossh/autossh). Then I realized that you are probably running ssh (reverse) tunnels. If that works for you, I don't think you should change! With others, I think its a mixed bag, in no particular order: * in my experience, opening up new connections in SSH is somewhat slow (compared to QUIC and ngrok). I believe this was due to how SSH verifies each new stream. * connet (and others that use UDP based protocols) don't experience the TCP head of line blocking issue. This might not be an issue necessarily, especially if you have a good, consistent connection between peers. * some of the other tools provide much richer interface (compared to raw SSH), like traffic inspection and modification, different security properties, etc * connet (and others) does allow multiple destinations and sources binding on the same name, so you can have multiple clients talking to a clustered service This is it off the top of my mind. Thanks for checking connet out!

Uptrenda 2y ago

Spent 2 years working on the same problem. Ended up designing a library that does: - direct connect - reverse connect - tcp hole punching - turn support Has other features too like: - multi-interface - duel-stack - port forwarding and pin holes Show some love cause its at 64 stars and is IMO, objectively better for direct peer-to-peer networking than OPs library that only supports direct, reverse, and relay, and which doesn't seem to do anything to open ports or firewalls. It does make me salty that I try so hard with my own work but what seems to make people successful is their ability to get lucky on sites like this or game them. No offense to OP. Here's my project: https://github.com/robertsdotpm/p2pd https://github.com/robertsdotpm/p2pd

yownie 2y ago
≥- duel-stack dual-stack unless they have sabers
- Uptrenda 2y ago
  Maybe they do, TCP hole punching is like a duel in a way. You are right tho, my spelling is horrible. Hope my message above doesn't come off in bad taste. I should be happy for the OP I guess.
Ingon 2y ago
connet is a young project, and draws inspiration from many great projects like yours. Thanks for sharing it, I starred it!
- Uptrenda 2y ago
  thanks man, sorry if i came off harshly will edit my post tbh, its a bad look. keep working on your project. I do see the need for what you're doing.
  - SupremeQuartz 2y ago
    "Love me overwatch. Love cheese pizza. Love Indian food. Love nature. Love the rain. Love me aul ma. Love me grand parents. Love ...love...love..." there ain't no god damn way, bro

linuxdude314 2y ago

You can do this with SSH alone. https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4e3e34a55d https://tenshidev.medium.com/ngrok-you-might-not-need-it-de4...

palata 2y ago
But with SSH you won't get NAT traversal and then the direct connection, right? You will forward through a server. Or am I missing something?