Named Data Networking (NDN) is a common network protocol for all applications and network environment.
NDN's network layer protocol runs on top of a best-effort packet delivery service, which includes physical channels such as Ethernet wires, and logical connections such as UDP or TCP tunnels over the existing Internet.
Using this underlying connectivity, NDN provides a content retrieval service, which allows applications to fetch uniquely named "Data packets" each carrying a piece of data.
The "data" could be practically anything: text file chunks, video frames, temperature sensor readings ... they are all data.
Likewise, a packet in a lower layer network protocol, such as an Ethernet frame, is also a piece of data.
Therefore, it should be possible to encapsulate Ethernet traffic into NDN Data packets, and establish a Virtual Private Network (VPN) through NDN communication.
This post describes the architecture of a proof-of-concept Ethernet-over-NDN tunneling program, and shows a simple performance benchmark over the real world Internet.
tap-tunnel creates an Ethernet tunnel between two nodes using NDN communication.
Each node runs an instance of
This program collects packets sent into a TAP interface, and turn them into NDN packets.
It then gains NDN connectivity by connecting to the local NDN Forwarding Daemon (NFD).
The diagram below shows the overall architecture:
OpenConnect VPN server, or
ocserv, is an SSL VPN server compatible with Cisco AnyConnect.
It can easily be installed in a cheap OpenVZ Virtual Private Server (VPS) with TUN capability.
However, most online tutorials for installing OpenConnect VPN server rely on
certtool to generate a self-signed certificate via OpenSSL.
Afterwards, since the self-signed certificate is not trusted by operating systems, either the VPN client must be configured to skip certificate checking, or the self-signed certificate must be imported as a trusted certificate on the VPN client machine.
Both practices are insecure.
Bypassing certificate checking would allow an attacker to impose as the VPN server.
Importing a trusted certificate does not seem wrong at first, but in case the private key is compromised, an attacker would be able to impose as any server to the client, including online shopping and bank websites, using a certificate signed by that private key.
Remember that the self-signed certificate's private key is stored on the VPS filesystem, it is much less secure than Hardware Security Modules used at real CAs to store private keys, and therefore it is a bad idea to trust such certificates in client machines.
Let's Encrypt is a free, automated, and open Certificate Authority (CA).
It allows anyone to obtain a domain-verified certificate within minutes, and without paying anything.
Certificates from Let's Encrypt are trusted by most modern operating systems.
They are ideal for securing an OpenConnect VPN server.
This article explains how to request a proper trusted certificate from Let's Encrypt for use with
ocserv, how to install OpenConnect VPN Server and use the Let's Encrypt certificate, and how to configure Cisco AnyConnect client to connect to
These steps are verified with an OpenVZ Ubuntu 16.04 64bit VPS provided by SecureDragon.
It is required to enable TUN devices for the VPS, typically through a button in SolusVM or other control panel provided by the hosting company.
Request Let's Encrypt Certificate for OpenConnect VPN Server
Before requesting a certificate from Let's Encrypt, you must have a Virtual Private Server with an IPv4 address, and have a domain name (could be subdomain) resolved to the server so that you are able to ping the server via the domain name.