4 ms·

What’s the problem with all devices connecting to a vpn server running somewhere? I mean, the usual access VPN solution. It’s not peer to peer, but you can set

by aborsy 4y ago

What’s the problem with all devices connecting to a vpn server running somewhere? I mean, the usual access VPN solution. It’s not peer to peer, but you can set up or rent a server near clients, like in the same city.

wmf 4y ago
A hub-and-spoke VPN is slower and it can be more expensive. It's easier if you're configuring each tunnel by hand, but now that mesh VPNs are easy to use you might as well use mesh.
- SOLAR_FIELDS 4y ago
  It’s also very much a reduction of what some of these technologies are capable of. For instance, I’ve used Netmaker somewhat extensively as a VPN solution, and I mostly agree with the sentiments that the original article expresses about Netmaker (young, unstable). However, that is not the most interesting use case that Netmaker offers at all. Rather, a much more interesting use case is something like having an easy and straightforward way for Kube pods in AWS and GCP spanning across multiple regions to talk to each other. Multi-cloud architectures are greatly simplified by these kinds of technologies, especially Netmaker, partly because of their abilities to punch through NATs. Also, Netmaker is kernel level WireGuard which is much more performant. If you’re just using Tailscale to talk to clusters from your MacBook, for instance, userland WireGuard is probably going to be more than enough. When you need servers to talk to each other, though, you usually need the extra perf
- linsomniac 4y ago
  It's not necessarily slower. It really depends on the connectivity of the VPN hub. At my previous company our VPN server was on a VERY good network, including InterNAP traffic optimizers. One of our employees ran some testing of it and found that in most cases going over the VPN was faster than natively using his Comcast connection. Comcast would tend to route the traffic over their own network links as much as possible. In the case of the VPN server, it was well enough connected that Comcast could get to it quickly, and the good connectivity it had (largely thanks to Level-3, but the InterNAP optimizer would help it pick great connections in any case), would get it to the final destination faster than Comcast's network could.
  - PLG88 4y ago
    I feel like you are answering your own question though... while a VPN hub and spoke can be faster than standard internet (by having peering relationships which are better than the users local telco - i.e., effectively circumvent and improve their standard BGP), you can do this on steroids with a mesh VPN by being able to deploy the relays into many diverse locations so that any user anywhere gets these benefits, even if they change location and access different resources. Its basically the same but more dynamic and distributed.
    - linsomniac 4y ago
      I'm not sure how I'm answering my own question, or how the question I was replying to is about mesh VPNs at all, I'm replying to "hub and spoke VPNs are slow". I'm just saying: It's not that simple. But, to clarify, when you say "relay node", are you talking VPN traffic relays (DERP nodes in tailscale parlance) or relays to the public Internet (exit nodes in tailscale parlance)? If the former, tailscale goes out of it's way to avoid the DERP servers and instead route traffic directly between the nodes (hence the "mesh"), so it doesn't gain the benefits of hub and spoke that I was speaking about, unless the src/dst nodes can't directly communicate. If the latter, I don't know of any mesh that has smarts about optimizing the reachability to the public Internet and shifting traffic between exit nodes to get better reachability. Can you mention a VPN that has the abilities you are speaking about, because I'm not aware of one, unless you somehow did something like integrating BGP into the exit node selection combined with something like a InterNAP traffic optimization appliance.
      - PLG88 4y ago
        Huh, I did not know that about TS, I thought they were always using the nodes. I was leaning on the former point (i.e., private applications rather than public internet), I know OpenZiti fabric does optimisation across available nodes by doing 'smart routing'. Interesting idea with the exit node and integrated BGP, not a use case ziti is trying to solve today but its a neat idea that is theoretically possible.
barnabee 4y ago
You are no longer "zero trust" as you have to trust the VPN server to verify the identity of the nodes, because the traffic to your node is not encrypted to and from another node (there are two encrypted tunnels between each of you and the VPN server, and the information that would allow you to verify the identity of the other node is stripped at the VPN server). Your VPN server also basically becomes a network switch in this case, doing the backhaul between all clients, which is likely to be expensive and slow compared to peer-to-peer connections. If you try to improve this by making the clients entire networks with switches/routers connected to each other only via internetwork VPN tunnels, then you also lose the property of the network that only known, verified nodes can be on that network. Not only can you not verify all nodes you connect to, neither can the VPN server (e.g. someone could plug a malicious or insecure device into the switch in your office, that would then have the same access to the network as other nodes).
- aborsy 4y ago
  Good point. But what would be the security difference between running a VPN server on a cloud instance, versus running a DERP/relay/coordination server on the same cloud? Sure, the traffic is decrypted on the VPN server in the hub-and-spoke case (even if most traffic is already encrypted by TLS and applications) but in both cases the server in the cloud could compromise the connection (in different ways, but correct me if I’m wrong that malicious servers used initially to establish the peer to peer connection cannot compromise the network, even with the Lock feature which prevents addition of unsigned public keys). You have to trust the cloud provider. Somehow people think mesh VPNs don’t need opening ports or are peer to peer. Not exactly: you just pass it to someone else to open ports for your network (used at minimum in the initial connection, and in the case of relays for the entire session). You have to trust the cloud in both cases, though in different ways. Further, at least your identity provider could act as an administrator with full privileges.
  - barnabee 4y ago
    Certainly there are potential exploits if you rely on a 3rd party cloud or service to run the coordination service, though these might be more limited than on a VPN server. Yggdrasil, assuming nodes operate their own identify based firewall as described the the original article, and tailscale if you use it with self hosted headscale rather than their coordination server can improve on this further. At work we run headscale on a physical machine we control for now. Personally I’m very interested in mesh networks like Yggdrasil and secure, radically open overlay networks and virtualised services in general.
goodpoint 4y ago
Increased latency, limited bandwidth, point of failures...

by aborsy 4y ago

wmf 4y ago

A hub-and-spoke VPN is slower and it can be more expensive. It's easier if you're configuring each tunnel by hand, but now that mesh VPNs are easy to use you might as well use mesh.

SOLAR_FIELDS 4y ago
It’s also very much a reduction of what some of these technologies are capable of. For instance, I’ve used Netmaker somewhat extensively as a VPN solution, and I mostly agree with the sentiments that the original article expresses about Netmaker (young, unstable). However, that is not the most interesting use case that Netmaker offers at all. Rather, a much more interesting use case is something like having an easy and straightforward way for Kube pods in AWS and GCP spanning across multiple regions to talk to each other. Multi-cloud architectures are greatly simplified by these kinds of technologies, especially Netmaker, partly because of their abilities to punch through NATs. Also, Netmaker is kernel level WireGuard which is much more performant. If you’re just using Tailscale to talk to clusters from your MacBook, for instance, userland WireGuard is probably going to be more than enough. When you need servers to talk to each other, though, you usually need the extra perf
linsomniac 4y ago
It's not necessarily slower. It really depends on the connectivity of the VPN hub. At my previous company our VPN server was on a VERY good network, including InterNAP traffic optimizers. One of our employees ran some testing of it and found that in most cases going over the VPN was faster than natively using his Comcast connection. Comcast would tend to route the traffic over their own network links as much as possible. In the case of the VPN server, it was well enough connected that Comcast could get to it quickly, and the good connectivity it had (largely thanks to Level-3, but the InterNAP optimizer would help it pick great connections in any case), would get it to the final destination faster than Comcast's network could.
- PLG88 4y ago
  I feel like you are answering your own question though... while a VPN hub and spoke can be faster than standard internet (by having peering relationships which are better than the users local telco - i.e., effectively circumvent and improve their standard BGP), you can do this on steroids with a mesh VPN by being able to deploy the relays into many diverse locations so that any user anywhere gets these benefits, even if they change location and access different resources. Its basically the same but more dynamic and distributed.
  - linsomniac 4y ago
    I'm not sure how I'm answering my own question, or how the question I was replying to is about mesh VPNs at all, I'm replying to "hub and spoke VPNs are slow". I'm just saying: It's not that simple. But, to clarify, when you say "relay node", are you talking VPN traffic relays (DERP nodes in tailscale parlance) or relays to the public Internet (exit nodes in tailscale parlance)? If the former, tailscale goes out of it's way to avoid the DERP servers and instead route traffic directly between the nodes (hence the "mesh"), so it doesn't gain the benefits of hub and spoke that I was speaking about, unless the src/dst nodes can't directly communicate. If the latter, I don't know of any mesh that has smarts about optimizing the reachability to the public Internet and shifting traffic between exit nodes to get better reachability. Can you mention a VPN that has the abilities you are speaking about, because I'm not aware of one, unless you somehow did something like integrating BGP into the exit node selection combined with something like a InterNAP traffic optimization appliance.
    - PLG88 4y ago
      Huh, I did not know that about TS, I thought they were always using the nodes. I was leaning on the former point (i.e., private applications rather than public internet), I know OpenZiti fabric does optimisation across available nodes by doing 'smart routing'. Interesting idea with the exit node and integrated BGP, not a use case ziti is trying to solve today but its a neat idea that is theoretically possible.

barnabee 4y ago

You are no longer "zero trust" as you have to trust the VPN server to verify the identity of the nodes, because the traffic to your node is not encrypted to and from another node (there are two encrypted tunnels between each of you and the VPN server, and the information that would allow you to verify the identity of the other node is stripped at the VPN server). Your VPN server also basically becomes a network switch in this case, doing the backhaul between all clients, which is likely to be expensive and slow compared to peer-to-peer connections. If you try to improve this by making the clients entire networks with switches/routers connected to each other only via internetwork VPN tunnels, then you also lose the property of the network that only known, verified nodes can be on that network. Not only can you not verify all nodes you connect to, neither can the VPN server (e.g. someone could plug a malicious or insecure device into the switch in your office, that would then have the same access to the network as other nodes).

aborsy 4y ago
Good point. But what would be the security difference between running a VPN server on a cloud instance, versus running a DERP/relay/coordination server on the same cloud? Sure, the traffic is decrypted on the VPN server in the hub-and-spoke case (even if most traffic is already encrypted by TLS and applications) but in both cases the server in the cloud could compromise the connection (in different ways, but correct me if I’m wrong that malicious servers used initially to establish the peer to peer connection cannot compromise the network, even with the Lock feature which prevents addition of unsigned public keys). You have to trust the cloud provider. Somehow people think mesh VPNs don’t need opening ports or are peer to peer. Not exactly: you just pass it to someone else to open ports for your network (used at minimum in the initial connection, and in the case of relays for the entire session). You have to trust the cloud in both cases, though in different ways. Further, at least your identity provider could act as an administrator with full privileges.
- barnabee 4y ago
  Certainly there are potential exploits if you rely on a 3rd party cloud or service to run the coordination service, though these might be more limited than on a VPN server. Yggdrasil, assuming nodes operate their own identify based firewall as described the the original article, and tailscale if you use it with self hosted headscale rather than their coordination server can improve on this further. At work we run headscale on a physical machine we control for now. Personally I’m very interested in mesh networks like Yggdrasil and secure, radically open overlay networks and virtualised services in general.

goodpoint 4y ago

Increased latency, limited bandwidth, point of failures...