 Tom here from Lawrence systems and our overlay networks, a VPN killer, or aren't they just another form of VPN? I look at them as a subset of VPN because you need to get your data that is over here on this network to wherever you are. And you need to tunnel that data somehow and a VPN seems like a good way to do this. But an overlay network is technically still a VPN. Matter of fact, one of my favorite ones, Tailscale uses WireGuard, which is a well-known VPN protocol to get the data from point A to point B and the coordination server helps make all that happen. I want to talk about the differences in architecture today between your traditional VPN that many know and the overlay networks which are becoming popular. I don't know that overlay networks are going to be the replacement for all solutions. They still have some, well, design challenges of whether or not they're supported on devices and they still then need another server that will then talk to them. We'll talk about how that works and some of the work around you may have to do if your device doesn't natively support the client. But I've also done longer videos on ZeroTier and Tailscale that are linked down below and Nebula. I put all those down and those are my in-depth tutorials. This is more just an architecture overview so you can understand the differences between them. And then if you're interested in one of them then you can pursue the full tutorial in the video down below, which does include a headscale video which does need to be updated. So if you just jump to the video, please note that at the time I made the video they did not have phone app support and they now have phone app support where you can change the destination and the Tailscale client on the phone so you can point it at a different headscale server. So I just want to make that note on there but everything else is still relevant and maybe I'll get around to an updated video on it. But let's jump over to our diagram and just kind of break down the differences between these two VPN types. We're gonna start here with a traditional VPN setup where your firewall, which has the public IP address is also the VPN. Now in enterprise networks, the VPN server may be separate from the firewall but for most users they're gonna be one and the same. The advantage you have here, this setup is gonna be simplicity. You wanna get from some untrusted network over to your home office network. It's gonna be your VPN on your firewall with a public IP address that you can access from other networks. You're gonna be most likely using open VPN, IPsec or WireGuard, which are all good protocols. They all have their pros and cons. Open VPN and WireGuard, probably being the two most prominent ones because they don't have many issues with that provided your firewall has a public IP address that's accessible and they are really secure. Now the normal access, especially maybe for a home user is gonna be, once you access the firewall, all the resources are now available to you on this network but you can get more advanced and I've done videos with radius plus PF sense and when you use a radius server you can then assign specific resources and then have granular firewall rules that say each user has a certain level of permissions that you define via rules for how they access things on a network. So they don't have to have access to everything. Maybe you only wanna give them access to some of the things but either way, this is a really simple, straightforward common way VPNs are done. It doesn't require any third party utilities either loaded on any of these servers. I think this is a very important to note that once you're in the perimeter network here, the NAS printer desktop windows server doesn't need any client software on there because as long as they can all talk to the firewall the firewall can talk to them via the VPN and you'll have access to those resources. Now let's talk about overlay VPNs. The way they work is by loading an agent on the devices that need access or that you want access to. We're gonna talk specifically about tail scale and zero tier because I have the most experience with them but most overlay systems work in a very similar way. You're gonna get your local IP address on your Linux server here and then you're gonna get an overlay IP address assigned to it. Now the overlay IP address stays static so even if your local IP address changes or what network you're on changes you always have this resource assigned to here when you set it up. Same thing goes with your system. So you can be on an untrusted network your local IP address be whatever was assigned to it doesn't really matter but your overlay IP address stays the same. Then your system and the other systems all the ones that have been built into this network are gonna go talk to the coordination server. The coordination server has a series of rules on it the coordination server needs to be publicly accessible doesn't have to be in the cloud but in the case of tails count zero tier they have their coordination servers that you can use and as long as your systems can talk to them they then begin the process of brokering the connections between the devices based on the access controls that you've defined in the coordination server that allow different devices to talk to each other. And if we split it all a little further the coordination server is not mean the data's passing through it it's coordinating the connections between these. Tail scale has a really good in depth right up on how UDP hole punching works it's an excellent network engineering guide not just a how tail scale works but really gives you a good understanding of how all this coordinates together and it's actually applies to a lot more than just tail scale but the coordination server is doing the client and looking at the public IP addresses by which each of these clients coming from and then sets up the data transport in a case of tail scale it's going to be using wire guard in the backend and then broker all these connections. So the connections actually become direct between the devices to get it a little bit more tricky this is actually a mesh network it builds because the coordination server not only depending on the rules you define in there allows your computer to maybe talk to these other resources you can actually have these resources talking to each other and in that case it doesn't go through the coordination server or out to the internet if they're still on the same network it'll actually connect the two devices on the same local network to talk to each other through these encrypted tunnels this is a really nice way that this system works but you may have noticed that I've took away the NAS and I've took away the printer as an option error we'll get to that in a moment but this is where you need an agent to make all this work on each of these devices and let's go a step further if you have resources that are in the cloud along with maybe multiple office networks they can all be coordinated together in much the same way the coordination server really is just building out a large mesh and figuring out the most efficient way for data to go from one server to the other based on the rules that you defined in the coordination server to get all these devices talking to each other provided they have an agent now if they don't have an agent this is handled in a few different ways in the case of PF Sense which is an easy solution if you have tail scale loaded with PF Sense it's going to talk to the coordination server PF Sense then it's going to let it talk to the local network because it can load as a plugin on PF Sense so instead of having to load an agent on each one of your devices you can actually use tail scale to coordinate getting into your network remotely the advantage it has especially is that you don't need a public IP address on your PF Sense in order to make this work so if you're stuck behind CGNet this is a great solution another option and this is going to vary is allowing the agent to run on one of these devices and then saying all right we're going to allow you to talk to local devices as well so that's another option where you do have some agents on the devices on the same subnets and the same networks you can talk to things like printers and you're just going to take the agent and use it as an exit essentially to get to the local network where these device resources are so that's another option I like the option of running it in PF Sense because it makes a lot of sense but I mentioned head scale the thing with head scale is it's a self-hosted version of tail scale and I've got a whole tutorial on it but what it allows you to do is not have to rely on a coordination server from a third party such as tail scale it allows you to host the coordination server yourself as long as it's publicly accessible then you are managing to control plane for which devices get authenticated because one thing to remember even though the data between the devices is encrypted you do have to have a lot of trust in the coordination server because the coordination server is what allows each device on the network now you shouldn't just say because a device has joined this overlay network it should automatically be trusted there still should be usernames and passwords for the resources that you expose with this but it's worth noting that if someone takes over the coordination server or whoever manages that coordination server they are allowed to add any other devices that they want to add to the overall network and that's why it's so important that you maintain control or have solid controls around that coordination server and some of you might be asking about Cloudflare tunnels of which I've done a video now this is not exactly I know Chris from Crosstalk did a great video on this as well I don't really look at this as a VPN killer but this is kind of a VPN replacement because you're taking internal resources and exposing them publicly there's some real advantage to doing next now you don't need a VPN at all so in some ways it's more of a VPN killer than overlay networks which are just really a different form of VPN but I think Cloudflare tunnels is a good solution I've done a video on it Chris from Crosstalk Solutions has done a video on it as well so has my friend from DB Tech though those are easy to find we've all talked about this because I think it's a neat way to expose things publicly but be very careful before you expose things publicly and as I mentioned in that video you are now placing trust in Cloudflare because they're the ones now brokering the connection by allowing a device inside of your network that you've controlled via Cloudflare to allow access to different things so Cloudflare becomes part of your circle of trust when you do this and making sure you configure it properly because now you've publicly exposed things now hopefully this clears up the difference for you between overlay networks and traditional VPN I don't have a better naming scheme form but I still want to call them VPNs I can't really get on board with calling them my VPN killer because they're still using VPN protocols and same principles on the backend to get your data from where you are to where the resources and get you connected through some type of private tunnel which sounds a whole lot like a VPN nonetheless, love to hear from you leave your thoughts and comments down below if you like this video if you have a different opinion on I shouldn't call these or if they are a VPN killer and we can certainly debate about that in the comments or head on my forums for a more in-depth discussion and thanks