4 ms·

Definitely interested in this, however: >Narrowlink uses a centralized gateway that clients and agents connect to over HTTP/S protocols Tunneling TCP over TCP

Definitely interested in this, however: >Narrowlink uses a centralized gateway that clients and agents connect to over HTTP/S protocols Tunneling TCP over TCP will undoubtedly result in poor network performance. This is why WireGuard is UDP-only.

pcthrowaway 3y ago
Isn't SOCKS typically tunneling TCP over TCP? SOCKS has been rock solid for me And on the other hand, HTTP/S is often using UDP for the transport now
- wmf 3y ago
  No, because SOCKS terminates the "inner" TCP connection at the proxy.
brutal_boi 3y ago
Tailsacle also has a series of performance optimization and wireguard testing blog posts; considering some of their late offload additions, and even though they use userspace wg, I find it hard to believe they are nowhere in the same perf ballpark, but I could be entirely wrong here...
benjaminl 3y ago
They should move to using QUIC which is the protocol backing HTTP/3. QUIC incorporates TLS1.3 and has an extension for UDP style unreliable datagrams (https://datatracker.ietf.org/doc/rfc9221/ https://datatracker.ietf.org/doc/rfc9221/). It would be the perfect way to bring SSL/TSL/HTTPS VPNs onto a modern performant protocol while keeping the simplicity in of the https based VPN. It would still have the advantage of looking like https traffic, while have the performance characteristics of UDP based VPN protocol.
SajjadPourali 3y ago
Hey, I am the creator of Narrowlink. I certainly find your comment valid, and using WireGuard over HTTPS most of the time provides better network performance. However, in very specific cases, Narrowlink demonstrates superior performance. 1- When your devices' routes are not optimal, and utilizing a CDN can enhance the connection due to smart routing. For instance, I have a server in Poland (while I live in Canada) where the direct connection is slower than connecting via Narrowlink behind the CDN (The gateway behind the CDN). 2- And in rare cases, Tailscale cannot establish a peer-to-peer connection, opting to use DERP servers and their own servers (no longer strictly P2P as seen here: https://tailscale.com/kb/1232/derp-servers/ https://tailscale.com/kb/1232/derp-servers/). In such cases, Narrowlink may provide faster connectivity. 3- When you start your Tailscale client, it needs to perform NAT discovery. If a symmetric NAT exists, it takes time to connect due to network flooding for UDP hole punching, while Narrowlink can respond on demand (see the section "The benefits of birthdays" on https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/). It's also important to note, alongside the protocol, the software implementation is crucial. Narrowlink is written purely in Rust, while Tailscale has been created by orchestrating existing tools and uses the Go and C++ programming languages. I suggest you try Narrowlink and experience its computational performance. I believe Tailscale is an amazing VPN solution, but its protocol, infrastructure, and complexities might not be the best fit for self-hosted platforms. In contrast, Narrowlink is a Proxy solution (currently not a VPN) that is very simple to set up. Please note that narrowlink only encapsulate the TCP payload's not its headers. I recently released Narrowlink (just two days ago), and it is in the early stages of its journey. I have various plans for this project, including a web interface, integration of the QUIC protocol, and more. I just need the support of the community and more time to enhance it.
- c7DJTLrn 3y ago
  Thanks for the detailed response. Nice work.
- anderspitman 3y ago
  Do you have an overview anywhere of the protocol you're using to encapsulate TCP in HTTP? Why did you go with HTTP instead of WebSockets? Does Narrowlink support UDP? Sorry for so many questions
  - SajjadPourali 3y ago
    Narrowlink uses the HTTP/S (WebSocket) protocol as transport; it encapsulates and decapsulates TCP and UDP connections on top of it. This means both UDP/TCP tunneling methods are available out of the box. For example, the following screenshot shows a UDP tunnel for DNS purposes and its encapsulated traffic as TLS (HTTPS+WebSocket=WSS). https://i.ibb.co/wcHB8g2/udp.png https://i.ibb.co/wcHB8g2/udp.png I also invite you to continue the discussion on the github https://github.com/narrowlink/narrowlink/discussions https://github.com/narrowlink/narrowlink/discussions You are most welcome

pcthrowaway 3y ago

Isn't SOCKS typically tunneling TCP over TCP? SOCKS has been rock solid for me And on the other hand, HTTP/S is often using UDP for the transport now

wmf 3y ago
No, because SOCKS terminates the "inner" TCP connection at the proxy.

brutal_boi 3y ago

Tailsacle also has a series of performance optimization and wireguard testing blog posts; considering some of their late offload additions, and even though they use userspace wg, I find it hard to believe they are nowhere in the same perf ballpark, but I could be entirely wrong here...

benjaminl 3y ago

They should move to using QUIC which is the protocol backing HTTP/3. QUIC incorporates TLS1.3 and has an extension for UDP style unreliable datagrams (https://datatracker.ietf.org/doc/rfc9221/ https://datatracker.ietf.org/doc/rfc9221/). It would be the perfect way to bring SSL/TSL/HTTPS VPNs onto a modern performant protocol while keeping the simplicity in of the https based VPN. It would still have the advantage of looking like https traffic, while have the performance characteristics of UDP based VPN protocol.

SajjadPourali 3y ago

Hey, I am the creator of Narrowlink. I certainly find your comment valid, and using WireGuard over HTTPS most of the time provides better network performance. However, in very specific cases, Narrowlink demonstrates superior performance. 1- When your devices' routes are not optimal, and utilizing a CDN can enhance the connection due to smart routing. For instance, I have a server in Poland (while I live in Canada) where the direct connection is slower than connecting via Narrowlink behind the CDN (The gateway behind the CDN). 2- And in rare cases, Tailscale cannot establish a peer-to-peer connection, opting to use DERP servers and their own servers (no longer strictly P2P as seen here: https://tailscale.com/kb/1232/derp-servers/ https://tailscale.com/kb/1232/derp-servers/). In such cases, Narrowlink may provide faster connectivity. 3- When you start your Tailscale client, it needs to perform NAT discovery. If a symmetric NAT exists, it takes time to connect due to network flooding for UDP hole punching, while Narrowlink can respond on demand (see the section "The benefits of birthdays" on https://tailscale.com/blog/how-nat-traversal-works/ https://tailscale.com/blog/how-nat-traversal-works/). It's also important to note, alongside the protocol, the software implementation is crucial. Narrowlink is written purely in Rust, while Tailscale has been created by orchestrating existing tools and uses the Go and C++ programming languages. I suggest you try Narrowlink and experience its computational performance. I believe Tailscale is an amazing VPN solution, but its protocol, infrastructure, and complexities might not be the best fit for self-hosted platforms. In contrast, Narrowlink is a Proxy solution (currently not a VPN) that is very simple to set up. Please note that narrowlink only encapsulate the TCP payload's not its headers. I recently released Narrowlink (just two days ago), and it is in the early stages of its journey. I have various plans for this project, including a web interface, integration of the QUIC protocol, and more. I just need the support of the community and more time to enhance it.

c7DJTLrn 3y ago
Thanks for the detailed response. Nice work.
anderspitman 3y ago
Do you have an overview anywhere of the protocol you're using to encapsulate TCP in HTTP? Why did you go with HTTP instead of WebSockets? Does Narrowlink support UDP? Sorry for so many questions
- SajjadPourali 3y ago
  Narrowlink uses the HTTP/S (WebSocket) protocol as transport; it encapsulates and decapsulates TCP and UDP connections on top of it. This means both UDP/TCP tunneling methods are available out of the box. For example, the following screenshot shows a UDP tunnel for DNS purposes and its encapsulated traffic as TLS (HTTPS+WebSocket=WSS). https://i.ibb.co/wcHB8g2/udp.png https://i.ibb.co/wcHB8g2/udp.png I also invite you to continue the discussion on the github https://github.com/narrowlink/narrowlink/discussions https://github.com/narrowlink/narrowlink/discussions You are most welcome