(This was a little bit triggered by the ongoing VPN woes, but the origin of my concern predates today’s Balena VPN outage.)
We are competing with products that have as a network security benefit “only one outgoing encrypted TCP connection, no ports exposed to the public Internet”.
Is it possible to achieve this with Balena?
I feel like the VPN-based model could end up being an issue for Balena, long-term. This makes it non-trivial to firewall ports so that there is no exposure of something that could have security issues to the public internet. Personally I must admit that I find it an odd model with clear downsides.
Another network model would be one using outgoing multiplexed and encrypted connection (TCP+TLS? HTTP/2?) from each device to Balena, and then tunnelling things like e.g. ssh over this connection.
How married is Balena to the VPN setup? What advice can you offer customers who want to minimize the amount of exposed ports?
A VPN is exactly what you describe: “only one outgoing encrypted TCP connection, no ports exposed to the public Internet”. The ports that are exposed on the VPN interface are not exposed to the public internet, they are solely reachable by a special subgroup of our servers, they are also not reachable from other devices (in case this is a concern).
If we imagine an outgoing multiplexed and encrypted connection as you suggest, and tunneling things like ssh etc. over this, this is in essence a re implementation of the VPN. Because the devices open up an outgoing multiplexed and encrypted connection (the VPN connection). We use this single connection to tunnel services to the device. Instead of building an application level tunneling to internal ports, we have a virtual network interface to communicate.
That said, we still offer the possibility to allow you to control the VPN connection on demand:
With the RESIN_SUPERVISOR_VPN_CONTROL environment variable (https://www.balena.io/docs/reference/supervisor/bandwidth-reduction/#example-minimum-bandwidth-settings) you can tell the device to not connect to the VPN network. This disables all services that rely on the VPN connection, like public url, and ssh access to the device. But the device will still fetch its state directly via HTTPS from the API and of course updates will work as well directly via HTTPS. So you can disable the VPN when you don’t need it, and re enable it when you need it again. I’m not familiar with your application, but if your use case does not need the VPN based services, this might be an interesting option for you.