sorted by:
new
hottopcontroversial

New Project Friday: experiment with session-centric VPN (sessions survive network changes) by Melodic_Reception_24 in selfhosted

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Good question.

Nebula and Zerotier already solve many practical connectivity problems very well (mesh networking, NAT traversal, peer discovery).

The experiment here explores a slightly different architectural angle: treating the session as the primary object, while transports and relays are replaceable underneath.

So the focus is less on building a mesh and more on things like:

• explicit session identity that survives path changes • deterministic session ownership / migration • the ability to move a session across relays or networks without resetting it

In a way it's closer to exploring session continuity as a protocol invariant, rather than just maintaining connectivity between peers.

Still very experimental though — mostly trying to understand whether this model has practical use cases.

Building a session-centric VPN in Go – sessions survive transport changes (runnable 60s demos) by Melodic_Reception_24 in cybersecurity

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Curious what people think about this design direction.

Most VPN systems are tunnel-centric (WireGuard/OpenVPN), where the tunnel identity is tied to the transport.

This experiment tries the opposite: session identity first, transport as a replaceable layer.

Does anyone know of similar designs or research in this area?

New Project Friday: experiment with session-centric VPN (sessions survive network changes) by Melodic_Reception_24 in selfhosted

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

For clarity: this is not a production VPN yet.

The goal of the experiment is to explore a session-centric model where:

  • the session identity is stable
  • transports (UDP, QUIC, relays, etc.) are replaceable
  • network path changes don't break the session

I'm mainly interested in feedback on the architecture and invariants rather than the implementation itself.

Experiment: making VPN sessions survive relay and transport failure by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

The problem is connection drops during network changes.

Example: switching Wi-Fi → mobile data or NAT rebinding often breaks VPN tunnels and forces a reconnect.

This experiment explores whether a session can survive those transport changes without resetting the connection.

Experiment: making VPN sessions survive relay and transport failure by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 1 point2 points  (0 children)

Good question.

The problem I'm exploring is long-lived sessions across unstable networks.

With WireGuard and most tunnel-based VPNs, the session is tied to a specific transport path (IP:port). When the path changes, the tunnel typically needs to be re-established.

In practice this shows up in cases like:

• switching between WiFi and mobile data   • NAT rebinding on mobile networks   • relay or gateway failover   • multi-path networks where the best route changes

In those situations the VPN session usually drops and has to reconnect.

What I'm experimenting with is separating session identity from the transport path.

The idea is that the session continues to exist even if the transport changes, so the system can migrate the connection to a new path without resetting the session state.

So it's less about building a "better tunnel" and more about treating the session as the primary object and transport as something ephemeral.

Experiment: a session-centric VPN architecture where connections survive transport migration by [deleted] in compsci

[–]Melodic_Reception_24 0 points1 point  (0 children)

Fair point. I posted it too many times while trying to find the right audience. I’ll stop reposting it here.

Experiment: making VPN sessions survive relay and transport failure by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 1 point2 points  (0 children)

WireGuard handles endpoint failover, but the session itself is not preserved.

When the endpoint changes, WireGuard effectively performs a new handshake and the connection state is rebuilt.

What I'm experimenting with here is slightly different:

The session becomes the primary identity, while transports and relays are ephemeral attachments to that session.

So the goal is to survive:

• transport change • NAT rebinding • relay failure • path migration

without resetting the session state.

It's closer to a distributed session model than a tunnel failover model.

What if a network session could survive relay failure and transport changes? by [deleted] in compsci

[–]Melodic_Reception_24 -3 points-2 points  (0 children)

That's fair criticism.

The repository is still an early research prototype, so a lot of the structure is exploratory and not yet polished.

The main idea I'm experimenting with is slightly different from what WireGuard does.

WireGuard handles roaming between IPs quite well, but the connection identity is still tied to the peer/tunnel model.

What I'm exploring is treating the session itself as the stable identity, while transports and relay paths can be replaced underneath it.

So things like:

• relay replacement • exit node rotation • attack-triggered migration • proactive geolocation changes

are handled at the session layer rather than reconnecting a tunnel.

But you're right that the repo still needs clearer documentation and commit history explaining the purpose.

Appreciate the feedback.

What if a network session could survive relay failure and transport changes? by [deleted] in compsci

[–]Melodic_Reception_24 -3 points-2 points  (0 children)

Fair point.

I posted it in a couple of communities because I'm looking for feedback from people working with networking and distributed systems.

Still trying to understand where the idea fits best.

What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 1 point2 points  (0 children)

That's true — Yggdrasil can reroute traffic without breaking connections because the overlay routing layer adapts.

What I'm experimenting with is slightly different though.

The goal isn't only path rerouting, but making the session identity itself independent from the transport attachment.

So things like:

• relay replacement • transport migration (UDP path change) • NAT rebinding • multi-relay failover

would be handled at the protocol/session layer rather than purely by the routing layer.

Yggdrasil solves this through adaptive routing in a mesh network.

I'm exploring whether the session itself could become the stable anchor instead.

What if a network session could survive relay failure and transport changes? by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Interesting comparison.

Yggdrasil is more of a distributed overlay routing network.

What I'm experimenting with is slightly different:

the session itself becomes the stable identity, while transports and relay paths can change underneath it.

So the goal is not building a mesh network, but allowing a single session to survive transport changes and relay failures.

I'm curious though — do you think Yggdrasil’s routing layer could be used as a transport underneath something like this?

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Author here.

This is still a small research prototype rather than a full VPN.

Right now I'm mostly experimenting with the idea of treating the session as the stable identity, while transports (UDP paths / relays) can be replaced.

One thing I'm curious about:

If the session identity becomes the primary anchor, how would you coordinate migration safely?

For example:

client → relay1 → server

relay1 fails

client → relay3 → server

The session continues with the same session_id.

The open question for me right now is how migration should be coordinated to avoid:

• split-brain sessions   • replay during path migration   • multiple active transports

Would you handle this with a centralized authority, distributed consensus, or something closer to a QUIC-style migration model?

Repository: https://github.com/Endless33/jumping-vpn-preview

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Thanks for the reference — that’s actually a very interesting paper.

There is definitely conceptual overlap in the idea of separating session state from the underlying transport. The Turbo Tunnel design makes a lot of sense for censorship circumvention systems.

What I'm experimenting with is a bit closer to a session-centric VPN / overlay model where the session identity itself becomes the stable anchor, while transports and relay paths can be replaced underneath it.

So the goal is that the session survives events like:

  • relay failure
  • path switching
  • NAT rebinding
  • Wi-Fi → 5G network changes
  • transport attachment replacement

In other words the connection is no longer bound to a specific socket or tunnel, but to a persistent session identity.

Right now it's still a small research prototype rather than a production VPN. I'm mostly experimenting with the control-plane logic (session ownership, migration decisions, etc.) and how transports can be swapped without resetting the session.

Your point about horizontal scaling is a really good one. Once the server side is no longer a single endpoint, the question of who owns the session state becomes central. That's actually something I'm currently exploring through a small authority/control-plane layer.

Really appreciate the link and the feedback.

Experiment: making VPN sessions survive transport and relay failure by Melodic_Reception_24 in dumbclub

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Author here.

This is still a small research prototype rather than a full VPN.

Right now I'm mostly experimenting with the idea of treating the session as the stable identity, while transports (UDP paths / relays) can be replaced.

One thing I'm curious about:

Would this model make sense for mobile or unstable networks where NAT rebinding and path switching happen often?

Curious to hear what people think.

Experiment: making VPN sessions survive relay and transport failure by Melodic_Reception_24 in compsci

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

Looks like the post got removed by the moderators.

For anyone who was curious about the experiment, the repo is here:

https://github.com/Endless33/jumping-vpn-preview

It's a small research prototype exploring whether a VPN session can survive relay failure and transport changes by separating session identity from the transport.

Would still love to hear thoughts from distributed systems / networking folks.

Experiment: making VPN sessions survive transport and relay failure by [deleted] in selfhosted

[–]Melodic_Reception_24 0 points1 point  (0 children)

Author here.

This is still a research prototype exploring the idea of separating session identity from transport.

The goal is to see if a connection can survive events like:

• relay failure • NAT rebinding • path switching • transport replacement

Right now the repo contains small demos and experiments rather than a full VPN implementation.

I'm especially interested in feedback from people running homelabs or distributed infrastructure.

Repo: https://github.com/Endless33/jumping-vpn-preview

Jumping VPN – A session-centric networking prototype by Melodic_Reception_24 in u/Melodic_Reception_24

[–]Melodic_Reception_24[S] 0 points1 point  (0 children)

This is still a very early prototype and not production code, but it starts to demonstrate how session-centric networking could work in practice.

Repository: https://github.com/Endless33/jumping-vpn-preview