I recently developed an embedded web server application for a control of a product. One of the issues to solve was the ability to access the product were ever it was. We wanted to avoid asking the customer to connect to the device to configure the network connections.
I implemented a system where the embedded system automatically configures with a VPN server at a known address and exchanges key data to allow VPN connectivity. The VPN server also implements a reverse proxy server for HTTP, to then allow web connectivity.
The VPN server is implemented with a Linux distribution. I used Ununtu, but any Linux would do. I used a basic LAMP installation and I added these additional packages:
To keep the interface secure, the web interface requires a login and password.
The Embedded server is also running Ubuntu Linux. Rather than the full LAMP it is configured with Apache2 and PHP only (no mySQL). The embedded server has heavy on CGI, as the web interface provides direct interactions with system hardware.
Device Configuration and Key Exchange
Each of the embedded devices needs to generate an SSH key pair. It then sends the public side of the key to the VPN server and gets a public key back from the VPN server. To facilitate this exchange, a listener (on a private IP port) on the VPN server receives requests from embedded device during the initial software installation of the device.
The protocol requires that the embedded device passes its host-name and MAC ID to the VPN server. If the request is validated, then the VPN server will look up the MAC ID in its database and return the VPN IP address to the embedded device. If the MAC ID is not currently in the database, it is added and a new VPN IP address is assigned.
The embedded device now updates its tinc host file (which contains the public key) with the new IP address. The updated file is transferred to the VPN Server. The embedded device also updates the “tinc-up” file to reflect the assigned address.
The VPN Server now stores the host file and returns its own host file to the embedded device. The VPN server now also updates the pound configuration to add the embedded system at an assigned post number. The port number and IP address are stored in the database.
With the exchange complete, both systems restart their tinc servers and the VPN server restarts the pound server.
With the VPN and pound configurations now established, a user can connect to the web server of the embedded system. However, the user needs to know the port number assigned to that device.
A connection to the VPN server on the standard HTTP port (80) will bring the user to a login screen. Following login a page with the available devices is listed. This list is dynamically generated based on the database content. A link is provided for each of the target devices. Selecting the link brings the user to the reverse proxy mapped port for the selected embedded device. The embedded system also requires a login.
The VPN system adds latency to the access to the device. As I sit in my office in Ithaca NY accessing the system next to me, the actual web traffic is flowing out on the public net to my public server in NYC and back. A round trip of around 450 miles. This is not a system I would want to use if the connection required significant bandwidth or immediate response. But as a method for service of remotely installed devices, it is quite suitable.
The VPN server is likewise a limiting element. As my usage is low and I only expect a couple connections at a time, a basic server is fine. It would need more substantial hardware to support a heavier user load.