Because OpenVPN devices are fully managed by the kernel, data transfers are invisible to the network, enhancing security and cross-platform compatibility.
I’m not going to talk about configuring OpenVPN in an AWS environment, for that you should read OpenVPN: Connecting VPCs between regions. We will try to go a bit deeper and learn exactly what’s going on under the hood.
I remember not too many years ago, we would ignore anything we’d hear about VPNs: those details are for the network team to worry about. But with the move to Cloud Computing Infrastructure as a Service models and the rise of DevOps, it’s coming much closer to home. I mean if, for instance, you’re working in a cloud environment like AWS, you will frequently encounter scenarios where you need to enable secured communication between VPC’s in different regions. The most obvious solution to that is some kind of virtual private network. And one of the more obvious virtual private network solutions is OpenVPN.
OpenVPN Introduction
OpenVPN is an open source VPN software solution licensed under GNU General public license (GPL) that enables secure point-to-point or site-to-site connections. OpenVPN can create interfaces from either layer 2 or layer 3 of OSI model using the industry standard SSL/TLS protocol, to provide secure connection and authentication mechanisms.
How OpenVPN works
The above diagram illustrates OpenVPN’s basic “client server mode” model. From one side, the OpenVPN server connects to the Internet, but at the same time, it maintains a secure communication channel with its clients. We’ll elaborate the working of TUN and TAP so as to understand the basic skeleton of any program attached to these interfaces. These program can be further extended to have OpenVPN kind of daemon or any other user defined behavior.
ll Internet traffic directed at an OpenVPN client is terminated at the server and transmitted to the client over a secure channel. Similar communication happens other way round, where any request originating from a OpenVPN Client is terminated at the server and then relayed to the Internet. This means that an OpenVPN client is known to the outside world only through the server’s identity, maintaining a higher level of privacy.
Communication between OpenVPN client and Server
Let us try to dig bit further and see how the communication channel connecting the OpenVPN client and server works. We’ll use a simple analogy. Usually a network interface in a computer has a physical device associated with it. For instance, ethernet interfaces have network cables attached that are used for physical data transfers. An OpenVPN connection is achieved through a virtual network interface backed by software.
This brings us nicely to the topic of TUN (“network TUNnel”) and TAP (“network TAP”). TUN and TAP are really virtual network interfaces implemented and managed by the kernel itself. So we can think of TUN/TAP as virtual ethernet interfaces.
The TUN interface
TUN is a virtual point to point network device whose driver was designed as low level kernel support for IP tunneling. It works at the protocol layer of the network stack.
The TAP Interface
TAP is a virtual Ethernet network device. TAP driver was designed as low-level kernel support for Ethernet tunneling. It works at the Ethernet Layer of OSI stack and aren’t limited to point to point connection as that of TUN devices.
Let’s go back to our analogy: when something is transferred through an ethernet interface, it’s sent through the cable. However, since TUN/TAP interfaces are virtual, data in transit can be available for just about any purpose to any program running in the user space.
OpenVPN implements a daemon which is attached to the TUN/TAP interfaces. So any data sent over a virtual interface is redirected by the kernel to the OpenVPN Daemon, which in turn implements the authentication and encryption mechanism.
How TUN and TAP work
TUN and TAP are fully managed by the kernel and allow user space applications to interact with them just like a real device. Any packets sent to these interfaces will be transmitted by the OS over the real network, remaining invisible to the user. Because it doesn’t require modification of the IP stack in the kernel space, this architecture is a key advantage of OpenVPN compared to other VPN solutions.
Let us try to understand the flow of data with virtual interfaces and a sample encryption application.
Let us assume two hosts, A and B, both configured with a virtual tap interface and an ethernet interface. Now we have an encryption application running in user space which performs some basic encryption. The encryption application has to keep track of two file descriptors:
- File descriptor obtained from attaching itself to the virtual interface, say tap_fd. When the program attaches to the tun/tap interface, it reads the data being sent from the interface from the special file descriptor.
- File descriptor received from opening a socket with the ethernet interface, say net_fd.
This application basically attaches and waits on some kind of select() on both the fd’s.
Now let us assume there is a communication channel over TCP established between the ethernet interfaces on Host A and Host B. The ethernet and tap interface at both ends are configured, up and running,
- A Telnet application uses the local virtual interface to send the data to the remote host.
- Since the encryption application is waiting for the tap_fd and net_fd file descriptors, it receives message over tap_fd descriptor and performs the required encryption.
- The sample client sends the encrypted message over the net_fd descriptor to be sent over the TCP channel.
- The ethernet interface (net_fd) at Host B receives the packet.
- Since the sample decryption server running at host B is also waiting on net_fd and tap_fd, it receives the packet at net_fd and performs the necessary decryption.
- After decryption, the sample server writes the data over tap_fd. When the data is written to the tap interface descriptor, kernel recognizes it as the message coming from the network or the wire, and executes it as if received from a normal ethernet interface.
Thus, the outside world only sees a normal TCP communication channel, but the actual data is sent in encrypted format and is never exposed.
The above flow of data provides a fairly simplistic view of how applications interact using TUN/TAP interfaces. The same logic is further extended by the OpenVPN application. OpenVPN allows the flexibility to use various client authentication and encryption mechanisms. The users, if they want, can use the built-in OpenSSL mechanism for authentication and encryption, or can go with an alternate approach using OpenVPN PAM – which provides a plugin module interface for exclusive or combined authentication.
With this blog I’ve tried to drop down one level to see what actually happens under the hood. You can find some additional background on this topic by reading Nitheesh Poojary’s excellent post, OpenVPN: Connecting VPCs between regions, which was written and published last summer. I hope this will help you better understand OpenVPN. I would really appreciate any comments or feedback you might have based on your own experience so we can all learn from each other.
