3 ms·

> Is what makes this a "P2P" VPN [...] that it supports the group/"community" network behavior? More or less! Compared to say OpenVPN there is no central serve

> Is what makes this a "P2P" VPN [...] that it supports the group/"community" network behavior? More or less! Compared to say OpenVPN there is no central server that all traffic is routed through (unless you choose to activate TURN of course, see the `--force-relay` flag), so hosting it is much cheaper as the only public part of the infrastructure is the part that exchanges the candidates ^^ Its pretty close to how n2n[1] does it, but has proper NAT hole punching support due to the WebRTC backend. > When you do that, are you building a full-connected overlay network [...] Yes! Its a full mesh; it seems to scale pretty well to a fairly large number of nodes, although I haven't tested it with more than ~100 peers in a single community yet. If the overhead of maintaining all of the connections is too much or peering between nodes in an issue, TURN can help to connect those peers with the rest of the mesh. Orchid looks interesting! [1] https://github.com/ntop/n2n https://github.com/ntop/n2n

saurik 4y ago
Wait, is the signaling server "public infrastructure"? Are you then having users pre-set/share all their DTLS keys and ICE passwords (to prevent the obvious MITM)? I don't remember seeing that in your documentation (but I am not reading it extremely carefully or anything). (This isn't an issue for Orchid as the endpoints are expected to expose signaling ports for WHIP.)
- pojntfx 4y ago
  Oh the signaling server is but a simple ICE candidate/offer/answer relay :) The messages being sent there are encrypted using a PSK so that the signaling server can't access the ICE candidates etc.
ackbar03 4y ago
Does this also work between two peers that are behind NAT's / routers? From what I vaguely remember when I tried playing around with this stuff, some NAT's / routers have some sort of port randomization thing so that the same ports don't always reach the desired location behind it. Does WebRTC make that port connection persistent due to the streaming nature of it; is that the idea? Does the stream ever break and does it require getting ip and port information from the STUN and ICE servers again? If so, how often does that happen?
- 411111111111111 4y ago
  The NAT hole punching they mentioned is a workaround for exactly that scenario. While I'm not involved in the project whatsoever, I'd expect that to work in most scenarios considering they've explicitly mentioned it. It's not a guarantee however and can get circumvented if the network owner wants to https://en.wikipedia.org/wiki/Hole_punching_(networking)#:~:text=Hole%20punching%20(or%20sometimes%20punch,network%20address%20translation%20(NAT) https://en.wikipedia.org/wiki/Hole_punching_(networking)#:~:....
- pojntfx 4y ago
  From my experience it works basically everywhere, but if it doesn't - just specify a TURN server on `--ice` and you'll be able to connect to a relay ^^ The ports/IP can actually change - I was traveling through Germany by train recently for example and whenever my public IP changed it signaled the updated candidates using trickle ICE :)

saurik 4y ago

Wait, is the signaling server "public infrastructure"? Are you then having users pre-set/share all their DTLS keys and ICE passwords (to prevent the obvious MITM)? I don't remember seeing that in your documentation (but I am not reading it extremely carefully or anything). (This isn't an issue for Orchid as the endpoints are expected to expose signaling ports for WHIP.)

pojntfx 4y ago
Oh the signaling server is but a simple ICE candidate/offer/answer relay :) The messages being sent there are encrypted using a PSK so that the signaling server can't access the ICE candidates etc.

ackbar03 4y ago

Does this also work between two peers that are behind NAT's / routers? From what I vaguely remember when I tried playing around with this stuff, some NAT's / routers have some sort of port randomization thing so that the same ports don't always reach the desired location behind it. Does WebRTC make that port connection persistent due to the streaming nature of it; is that the idea? Does the stream ever break and does it require getting ip and port information from the STUN and ICE servers again? If so, how often does that happen?

411111111111111 4y ago
The NAT hole punching they mentioned is a workaround for exactly that scenario. While I'm not involved in the project whatsoever, I'd expect that to work in most scenarios considering they've explicitly mentioned it. It's not a guarantee however and can get circumvented if the network owner wants to https://en.wikipedia.org/wiki/Hole_punching_(networking)#:~:text=Hole%20punching%20(or%20sometimes%20punch,network%20address%20translation%20(NAT) https://en.wikipedia.org/wiki/Hole_punching_(networking)#:~:....
pojntfx 4y ago
From my experience it works basically everywhere, but if it doesn't - just specify a TURN server on `--ice` and you'll be able to connect to a relay ^^ The ports/IP can actually change - I was traveling through Germany by train recently for example and whenever my public IP changed it signaled the updated candidates using trickle ICE :)