Not quite the same thing, you can’t do layer 2 VPNs on wireguard (I ended up using tinc for that on a previous project, it worked well). For layer 3 however it’s really good. Fast, simple, reliable, client works well on the platforms I’ve tried so far.
My case for it was dealing with proprietary sensor devices with ethernet ports and garbage firmware. They could work if your server was on a different subnet, but a bunch of stuff broke (including the config tool) if you were not on the same ethernet LAN. The L2 tinc VPN allowed us to fix things without needing to walk around to the dozens of devices in a building with an ethernet cable, laptop and a ladder.
The firmware (& vendors) of the devices that we spent over 100K on were garbage in so many ways. One product’s proprietary server software would misbehave (read: open files but never close them, after a time running out of file descriptors) which would then cause its fleet of individual sensors to all start SYN flooding it. Another brand’s device model required us to spend lots of time manually updating them through every version of firmware because you were not allowed to jump straight to the latest version. I think it took an hour to complete the process for each unit (during which they’d get really hot and presumably throttle).
A bonus of tunnelling things back to our server over tinc was that everything was now encrypted. I used cheap GL.inet “mango” routers running OpenWRT to backhaul the sensors over the existing shared wifi network (rather than needing dedicated copper or wired VLANs). They worked almost like magic – a weird wifi stack reliability issue required me to write a watchdog that rebooted them, however, otherwise we were back on ladders every few days :| But once that pain was over things overall worked much better.
Aside: Don’t buy ANY off-the-shelf sensor product without first:
Confirming that you’re not tied to their proprietary server software. Them claiming that they speak an open protocol is NOT enough.
Buying a few to actually test the above AND reliability over the span of at least a week’s operation AND that they’re not just outright lying about the device’s accuracy/reliability/usefulness/etc
I made the mistake of being on holidays when the decisions on what to buy were made :P I ended up designing and building some of our sensor devices (somehow at a cheaper price even including my labour) that worked better for us, but shortly afterwards the funding ran out and I got a job elsewhere.
Nowadays Wireguard is a more performant protocol, but it does the same thing.
Not quite the same thing, you can’t do layer 2 VPNs on wireguard (I ended up using tinc for that on a previous project, it worked well). For layer 3 however it’s really good. Fast, simple, reliable, client works well on the platforms I’ve tried so far.
Good to know! What’s the practical use for a L2 VPN?
My case for it was dealing with proprietary sensor devices with ethernet ports and garbage firmware. They could work if your server was on a different subnet, but a bunch of stuff broke (including the config tool) if you were not on the same ethernet LAN. The L2 tinc VPN allowed us to fix things without needing to walk around to the dozens of devices in a building with an ethernet cable, laptop and a ladder.
The firmware (& vendors) of the devices that we spent over 100K on were garbage in so many ways. One product’s proprietary server software would misbehave (read: open files but never close them, after a time running out of file descriptors) which would then cause its fleet of individual sensors to all start SYN flooding it. Another brand’s device model required us to spend lots of time manually updating them through every version of firmware because you were not allowed to jump straight to the latest version. I think it took an hour to complete the process for each unit (during which they’d get really hot and presumably throttle).
A bonus of tunnelling things back to our server over tinc was that everything was now encrypted. I used cheap GL.inet “mango” routers running OpenWRT to backhaul the sensors over the existing shared wifi network (rather than needing dedicated copper or wired VLANs). They worked almost like magic – a weird wifi stack reliability issue required me to write a watchdog that rebooted them, however, otherwise we were back on ladders every few days :| But once that pain was over things overall worked much better.
Aside: Don’t buy ANY off-the-shelf sensor product without first:
I made the mistake of being on holidays when the decisions on what to buy were made :P I ended up designing and building some of our sensor devices (somehow at a cheaper price even including my labour) that worked better for us, but shortly afterwards the funding ran out and I got a job elsewhere.