Image courtesy of wireguard.com.
WireGuard® is a new communication protocol that implements encrypted virtual private networks (VPN). It endeavors to provide network agility, advanced security, performance, and configuration simplicity. Back in 2017 Jason A. Donenfeld, a security researcher and Linux kernel developer, was looking for a stealthy traffic tunneling solution for use in penetration testing jobs. In an interview on the Security. Cryptography. Whatever. podcast, Donenfeld explains that while he was “familiar with OpenVPN and IPSec” he was well aware of the bugs these solutions carried with them. Thus, he set out to create something new for himself that would not suffer from historical technical debt.
IPSec, one of the major VPN options available today, was born in 1992 with the Internet Engineering Task Force’s formation of the IP Security Working group, and was standardized in 1995 under RFC-1825 and RFC-1827. IPSec has always required a tremendous amount of configuration unique to the hardware and software environments it will then connect. The encryption, key exchange, and authentication algorithms that it supports are overly broad, in order to support legacy equipment. The key exchange mechanism can be prone to rekeying issues, causing stability problems. This is not to say that IPSec should be avoided, but to point to the non-triviality of its implementation. If you consider using IPSec as a vehicle for remote worker VPN connections (“people VPN” or “road warrior VPN”), there are security concerns as simple as an “aggressive mode” sending a hash of pre-shared keys in plain text.
Another option, OpenVPN, was initially released in 2001 by James Yonan. It uses Secure Socket Layer (SSL) and Transport Layer Security (TLS) to provide encryption. OpenVPN is currently the most widely used VPN protocol on the planet, to the extent that some might consider it the backbone of modern online security. Along with trusted encryption, OpenVPN also supports a wide range of algorithms for encryption and authentication, hashing, and key derivation, making it highly adaptable to different deployments. It also uses certificates for identification and encryption and it can operate on UDP or TCP.
This brings us back to the steady emergence of WireGuard. In January of 2020 Linus Torvalds merged David Miller’s “net-next” tree into the Linux kernel, bringing WireGuard into the mainline Linux kernel tree. WireGuard was written to be efficient and easily readable; it is comprised of around 4,000 lines of code, which is much fewer lines of code than OpenVPN relies on. Among other benefits, this smaller size makes WireGuard auditable in an afternoon (or so) and the condensed code significantly reduces the attack surface. The goal is to keep WireGuard slimmed down to its basic operational function; a simplified and performant VPN. It is left to third parties to extend it to meet various functional business requirements.
While IPSec and OpenVPN provide a plethora of algorithmic options, WireGuard limits the need for user choice and customization in favor of fast, modern cryptographic primitives that don’t rely on hardware accelerators. This greatly removes the possibility of user miscalculation and thus insecure or improper deployments. Many connectivity vulnerabilities are caused by the combination of primitives, not always the primitives themselves. WireGuard endeavors to combine known, secure, and performant primitives, and allows you to negotiate protocol versions to easily address future vulnerabilities.
WireGuard operates much like OpenSSH in terms of public and private keys. Peers identify themselves with a unique public keys which are is used to establish their IP inside of the tunnel. WireGuard calls this concept “cryptokey routing”. This simplification of tunnel configuration is a major advantage of WireGuard. Performance is another major factor of WireGuard’s appeal. OpenVPN adds about 20% data overhead while IPSec adds around 10%, but WireGuard uses a mere 4% more data than an unencrypted connection. Most tests even show WireGuard performing around twice as fast as OpenVPN, with WireGuard operating near to or close to line speed. Another key factor to the speed of connectivity is where WireGuard operates in the operating system. On Linux, WireGuard operates in kernel space, where packets are processed at a much faster rate. However, on Windows this is not the case, so the WireGuard group has developed a very simple and minimal TUN driver, Wintun, for the Windows kernel that shuttles packets to the Windows User Space. We can probably expect WireGuardNT (LINK) to move into the Windows kernel space in the future.
Back to the cryptokey routing table. The “cryptokey routing” concept developed by WireGuard allows changes to external source IPs to be picked up and propagated quickly and efficiency. Whether you are a roaming client that is switching between cellular and wifi, or a client that needs to ‘fail over’ to a backup server, the cryptokey routing table gets updated in mere seconds with the new IPs of the tunnel. In comparison, OpenVPN can take 30 seconds to reestablish new IP connections, which is only slightly slower than the time it takes IPSec connections using BGP routing to reestablish similar connections. The WireGuard protocol provides additional security in that it does not respond to packets from non peers nor unauthenticated packets, leaving WireGuard mostly invisible to non-peers.
In conclusion, it appears WireGuard aims to keep its code base small, be easy to implement and audit, all while having blazingly fast performance using state-of-the-art cryptography.
“WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.
Since the release of OpenVPN 2.5 the OpenVPN Project has moved it’s installer from an EXE (executable file) to the more modern MSI (windows installation file) method. MSI files have some clear advantages so no surprise that they have gone this route.
Previously the OpenVPN EXE had well documented installation parameters for their Windows installer:
/S – silent installation
/D=path – specify a custom installation path
Note – the /D parameter has to appear last on the command line, and the path may not be enclosed in quotes. The installer simply takes all of the command line left, and uses it as path (thus supporting spaces in the path).
To select individual OpenVPN components (1 = install, 0 = do not install; the values below indicate defaults):
/SELECT_SHORTCUTS=1 – create the start menu shortcuts
/SELECT_OPENVPN=1 – OpenVPN itself
/SELECT_SERVICE=1 – install the OpenVPN service
/SELECT_TAP=1 – install the TAP device driver
/SELECT_OPENVPNGUI=1 – install the default OpenVPN GUI
/SELECT_ASSOCIATIONS=1 – associate with .ovpn files
/SELECT_OPENSSL_UTILITIES=0 – install the utilities for generating public-private key pairs
/SELECT_EASYRSA=0 – install the RSA X509 certificate management scripts
/SELECT_PATH=1 – add openvpn.exe in PATH
/SELECT_OPENSSLDLLS=1 – dependencies – OpenSSL DLL’s
/SELECT_LZODLLS=1 – dependencies – LZO compressor DLL’s
/SELECT_PKCS11DLLS=1 – dependencies – PCKS#11 DLL’s
These parameters are useful and necessary when performing an unattended or programatic installation. Unfortunately with the release of 2.5 and the moving to an MSI installer these parameters no longer work and at the time of this writing the OpenVPN Project has not documented new parameters. Luckilyfor us MSI files have some basic characteristics and behaviors.
You can run any MSI file with logging like this:
msiexec /i installer.msi /l*v log.txt
It will pop up your installation GUI and you can then pick the customize option and choose the combination of features that you need. Once complete you can open your log file that you signified and search for ADDLOCAL. In our case where we desire to install only the OpenVPN Service and the new Wintun Drivers we find this:
ADDLOCAL=OpenVPN.Service,OpenVPN,Drivers,Drivers.Wintun
We can now run the installer on subsequent windows servers with the following command:
msiexec /i OpenVPN-2.5.0-I601-amd64.msi ADDLOCAL=OpenVPN.Service,OpenVPN,Drivers,Drivers.Wintun /passive
If we wanted to change the installation directory we could do so like this:
msiexec /i OpenVPN-2.5.0-I601-amd64.msi PRODUCTDIR=”C:\Program Files\OpenVPN25\” ADDLOCAL=OpenVPN.Service,OpenVPN,Drivers,Drivers.Wintun /passive
If you are looking to install the GUI and the older Windows TAP adapter you would do so like this:
msiexec /i OpenVPN-2.5.0-I601-amd64.msi ADDLOCAL=OpenVPN.GUI,OpenVPN,OpenVPN.GUI.OnLogon,Drivers.TAPWindows6,Drivers /passive
So there you have it. An easy work around to perform silent windows installations. Hopefully this will save some time and effort for people looking to utilize the new OpenVPN 2.5 client in their DevOps environments.
The new OpenVPN 2.5 client brings with it a new adapter type for Microsoft Windows. OpenVPN 2.5 has implemented the WireGaurd Wintun adapter. From the Wintun description: “Wintun is a very simple and minimal TUN driver for the Windows kernel, which provides userspace programs with a simple network adapter for reading and writing packets. It is akin to Linux’s /dev/net/tun and BSD’s /dev/tun. Originally designed for use in WireGuard, Wintun is meant to be generally useful for a wide variety of layer 3 networking protocols and experiments. The driver is open source, so anybody can inspect and build it. Due to Microsoft’s driver signing requirements, we also offer precompiled and signed versions, and ways of including it in Windows installers. The goal of the project is to be as simple as possible, opting to do things in the most pure and straight-forward way provided by NDIS.”
What does this mean for OpenVPN being utilized for encrypted overlay networks? Well first it has significant performance characteristics over the previously implemented TAP adapter; somewhere in the order of double the throughput. Which is more than significant in itself. Though there is another area that it really brings some much needed improvement and that is in it’s ability to handle UDP Multicast traffic. Multicast in cloud has always been a blocker for bringing a huge amount of applications from fully controlled and owned on premise networks to cloud networks which allow for a subset of networking protocols. Multicast has traditionally been used, apart from video streaming and some other applications, for autonomic; things like service election, clustering and discovery. To some extent this has forced new design patterns to make up for this lack of traditional network protocols. Though there has been a way to take these unsupported protocols to the cloud and that is through utilizing overlay networks; laying a layer 3 network over the top of an existing layer 3 network.
Employing a complex method of running a network on a network is something Cohesive Networks has always strived to simplify for the operator. This architecture does however require stable and performant entry points. Which brings us back to the new OpenVPN 2.5 client. The Wintun device driver fixes things, it’s not just more performant. Microsoft Windows in cloud has always been a bit broken in the virtual world. Point in fact is that by default it sets up routes to the full multicast network (224.0.0.0/4) on its primary ‘virtual’ network interface cards in cloud, where no such capabilities exist. The fix is to setup a startup script to delete this route if you are going to implement an overlay network to actually handle this traffic. Moreover the previous implementations of TAP adapter drivers have had issues with joining and leaving multicast groups without a restart of the entire network stack, i.e. rebooting.
Like many things cloud, there were many clever ways to work around these things, even though these workarounds often introduced new quirky limitations. Wireguard’s Wintun network adapter driver clears out some of these problems in the world of Windows. We now have a performant virtual network adapter that handles protocols in expectant ways that can be used to build overlay networks where the operator has full control, visibility and attest ability. Not every application needs to be rewritten for new patterns. Products like Cohesive Networks VNS3 can help you achieve architectural flexibility. Frameworks that allow you to design for today and tomorrow. Another step in the journey to the cloud.
As more and more businesses decide to suspend travel and close offices in response to the spread of COVID-19, the global workforce is becoming increasingly distributed (see Smarter with Gartner COVID-19 ). We support these decisions to reduce intersection points and help prevent the spread of the virus. We want to help in our own way to make this transition easier for business teams that don’t already have a secure remote work solution or need an alternative that is easy to setup and works.
Our core business is providing enterprises with cloud edge connectivity and security solutions. This typically doesn’t include remote working solutions like roadwarrior VPN or PeopleVPN (as we call it). That said, we do have some customers who utilize our VNS3 hybrid overlay network appliance to provide their distributed work force with secure connectivity to their data center and cloud based assets. We also have been using VNS3 internally to securely connect and protect our distributed workforce since 2009. Based on these use-cases we think we can help those who don’t have a simple and secure remote work solution.
VNS3 PeopleVPN available today for free for 6 months
We are making a custom, pre-configured version of our VNS3 network controller called PeopleVPN for remote work solutions available for free in both AWS Marketplace and Azure Marketplace.
VNS3 PeopleVPN capabilities include:
If you aren’t already using AWS or Azure for your cloud computing needs, take a look at their “free tier” offers to keep the cost of your remote work solution near zero:
While we have no delusions about our impact on this global crisis (we aren’t the Gates Foundation ), we want to do something to help. We believe that everyone has a communal obligation to help in any way. This is our way. We will not make any money from VNS3 PeopleVPN during the COVID-19 outbreak and we are committed to supporting any and all users during this challenging time.
Housekeeping:
Other Organizations looking to help (this list is not exhaustive, and we are happy to add):
Updated 3/18/2020 to include links to AWS and Azure Marketplace listings.
IPsec Networks
IPsec is a protocol suite for securing IP (transport layer) communications between peers by authenticating and encrypting each packet of communication.
In the network diagrams, the two red lines represent IPsec tunnels from a VNS3 Controller to the two remote firewall devices. The London and Chicago locations are two different endpoints.
An IPsec tunnel is built between two endpoint devices that “speak” the network standard. You can think of the following two phases and these two devices cordially introducing themselves and establishing a connection via an appropriately firm and friendly handshake.
IPsec negotiation is divided into two phases:
What is an IPsec based VPN?
An IPsec based VPN is made up of two parts:
Basically there is an initial brief interaction where one or each of the devices attempt to discover each other, via the Internet, they then trade Phase 1 (IKE) parameters and attempt to get a Phase 1 (sometimes called IKE or ISAKMP) connection which creates the keys used to encrypt Phase2. They then trade Phase 2 parameters and attempt to create an encrypted Phase 2 (sometimes called IPSec SA or ESP) tunnel connection.
IPsec negotiation is divided into two phases:
Phase 1: Initial negotiation phase. Peers find each other over the internet and trade security parameters in order to create “session keys” that prove they are who they claim to be. This is what security experts call a key exchange, and the peers use the Internet Key Exchange Protocol (IKE) to validate each other’s security claims.
Phase 2: Peers trade Phase 2 security parameters. The peers trust each other, and now can create an encrypted tunnel that connects them using IPsec Protocol Encapsulating Security Payload (ESP) to encrypt the IP Packet. That way, no one else can see what data is traveling between the peers. Even if someone was able to see the data, it is all encrypted and unreadable without a secure key.
How does an IPsec VPN work?
IPsec is able to secure packets as they travel across an IP network, usually between two sites separated by the public Internet. IPsec uses cryptographic security services to authenticate and encrypt each data packet as it travels two endpoints and protects that data from traffic sniffers.
IPsec connections ensure data isn’t read or tampered with when it travels across any type of network. IPsec is especially important when you’re building hybrid deployments between public cloud providers or the public internet.
IPsec has 2 types of implementation: a host-to-host transport mode, or network tunneling mode:
Transport mode
In transport mode, only the payload of the IP packet is usually encrypted and/or authenticated. Transport mode does not change the routing, since IP headers aren’t modified or encrypted. Transport mode works best in host-to-host connections.
Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. Tunnel mode must encapsulated the headers into a new IP packet with a new IP header. VPNs use tunnel mode for network-to-network communications, host-to-network communications, and host-to-host communications. Tunnel mode does support NAT traversal.
Recent Comments