OpenVPN vs. WireGuard – A Short Comparison
ungleich.ch
ungleich.ch
Another problem is that I did not found a way for Windows to keep tunnel up all the time. There's some way for "Always on" connection, but I couldn't configure it, there's no GUI option and it seems to require a lot of powershell magic and no easy to follow tutorials.
Another problem with IPsec is that only strongswan can provide adequate implementation. OpenBSD iked daemon can't send certificate chain, so I can't use Letsencrypt certificate. Libreswan does not support MSCHAP-V2 protocol, so easy configuration with username/password is not possible. Also default strongswan configuration does not allow Windows clients to connect without further tweaks (Windows does not want to use strong ciphers and strongswan does not want to use weak ciphers).
It's a mess.
So, yeah, wireguard might be interesting for me, as I still did not find a suitable solution which checks all the boxes. IPsec works for me, but it's not ideal.
Last time I checked, wireguard for Windows was in beta, but it looks like it's stable now according to the website. I guess it's worth to try it now.
Is this regarding server or client implementation? Are the client implementations of major operating systems (eg. Windows, Mac, iOS, Android) secure?
Regarding security: I had to reduce cipher strength to allow Windows client without further configuration. I'm using aes128-sha1-prfsha1-modp1024 which IMO should be relatively secure for home usage, but it's not very secure against governments. It's possible to use stronger ciphers, but you need to use some registry changes or powershell snippets for that, and I wanted to keep configuration to GUI dialogs. I have no idea why Windows by default does not accept strong ciphers.
So, I had to find an alternative. So far, I’ve tried WireGuard, ZeroTier, and now OpenVPN via Mullvad.
I just couldn’t get reliable connectivity with WireGuard and ZeroTier on all my devices, regardless of the configuration I used. OpenVPN is known to be slow and a CPU hog, but at least it seems to work. And I’ve done speed tests with fast.com and DSLReports, and both show me getting ~20-30 mbps or faster download speeds while on VPN, and that’s not much slower than what I was getting when off VPN. And “wehe” shows that I was getting throttled by the carrier even when on WiFi, not just on cell. Now, I’m not throttled at all.
I have not yet noticed any problems with extreme battery loss or high CPU, but we will just have to wait and see.
Point-to-point is annoying because you have to update every node when you add or change a node, but we have appreciated the HA aspect of it.
Of course I'm sure you can do point-to-point with OpenVPN and you can do gateways with Wireguard, but the design of them does influence how they're used.
I don’t particularly like this approach, definitely prefer how OpenVPN handles both routing updates (subnet push) and 2FA, despite its other flaws (slower, especially).
Since your are connected to the server using Wireguard, you don't need to check its identity you can just open the correct port, read the rules and apply them, a simple Python or Perl script should be able to do what you want.
The last time I tried OpenVPN the client seemed to primarily be a vehicle for displaying ads for a VPN service that I wasn't interested in (I wanted to VPN back to my home network, not to an endpoint in another country).
I don't know what you used, but the official OpenVPN apps are all ad free as far as I can tell.
This is "OpenVPN Connect" by "OpenVPN Technologies".
The app store listing currently shows that they removed the Private Tunnel section and made that into a separate app. The private tunnel is the advertising I was referring to.
They run something like Ethernet over IP, so your "segment" auto-configures via normal ARP, as if it were a LAN, as long as your devices have a connection. What's great e.g. for laptops and phones is that devices physically on the same network do talk directly, not via a VPN proxy node.
a simple dashboard to set up and manage a wireguard vpn server
I believe always-on is one option, but the option that intrigues me the most is to automatically connect when a certain domain is requested after a lookup failure. If you have an internal domain, say, ".randomtisk", you can set it to try, then connect the VPN if the DNS lookup fails - this way it will work normally at home and transparently connect to the VPN when you're away.
NOTE: I haven't actually tried this yet, it's a work in progress.
And it works pretty much the same way on all platforms, and it recovers seamlessly from switching cell phone towers and wifi APs.
https://www.reddit.com/r/WireGuard/comments/cor7ze/wireguard...
Is unsolved.
tl;dr: OpenVPN is ipv4, bad, Wireguard, ipv6, good.
I tried wide variety of VPN solutions, including Wireguard, IKEv2, OpenVPN, L2TP/IPsec, PPTP. Eventually I came to conclusion: I don't need VPN at all with all it's packet-level machinery, I just need fast encrypted proxy for browser and IM to forward my TCP connections securely.
And in practical terms, even Wireguard is not fastest substitution for proxy because packet loss on last mile (roughly) causes delays comparable to RTT between client and destination server versus proxy where retransmit on last mile packet loss occurs only between proxy server and client (it's also true for OpenVPN in TCP mode, but it has much more serious downsides caused by packet encapsulation inside stream protocol). Despite that fact Wireguard and other packet-level tunnels have higher theoretical throughput (from server point of view), simple TCP-to-TCP connection forwarding often gains higher practical speeds and more durable if such TCP-forwarding do not depend on state of underlying tunnel. So I decided: forward each TCP connection in separate encrypted connection will be just fine.
There already exist software which allows to wrap SOCKS in TLS or SSH (for example stunnel or haproxy for TLS case and OpenSSH for SSH case), but TLS handshake delay for each connection kills speed benefits for typical browsing scenario. Dynamic port forwarding via SOCKS proxy built-in into OpenSSH client has another drawback: all forwarded connections multiplexed into single one and in real networks with packet loss it makes high speeds unapproachable.
For these reasons I decided to re-implement both stunnel and OpenSSH client for connection forwarding purposes.
Here it is: https://github.com/Snawoot/ptw - TCP-to-TLS wrapper, which keeps pool of established TLS connections in order to cancel TLS handshake delay. May serve as transparent proxy on Linux router (sends haproxy PROXY-protocol v1/v2 in connection prologue) or serve as wrapper for plain SOCKS/HTTP/whatever proxy.
And second one: https://github.com/Snawoot/rsp - Rapid SSH Proxy, faster [1] replacement to `ssh -ND`. It also uses connection pooling, and, unlike default OpenSSH client, maps TCP connections one-to-one to SSH connections. You don't need any setup on server side: working SSH server should be already enough.
And this is how I quit hating. Now I don't need to turn proxy on/off, because it doesn't imposes performance penalty. In SpeedTest I achieve almost full connection speed (mine is 100Mbps) with ptw or rsp (versus 50Mbps with wireguard).
personally, i found wiresharks documentation confusing and left me unsure of the best practices. im sure if i used it regularly it would be clear, this was just my first impression and then I left it behind.