I’d missed some of the possible nuance of that, though perhaps because the goal is less than clear.
So what I’d say is:
-
Running other sorts of “box in the field” things of the sort that people are already making OpenWrt do can be reasonable - one certainly needs to watch image size, network, usage, and beware anything that could cause the system overall to pause, but in general terms a gateway can juggle other tasks within reason.
-
VPN solutions are things people commonly put on gateways not really to protect their traffic, but to give a path in for remote administration: as such they’re one of maybe three classes of solution: virtual network actually allowing inbound connection, SSH outbound connection with a port forward back in, and task-based daemons that poll a dispatch server for specific commands and run them. There are probably other ideas, too. Both VPN and SSH tunnel solutions are commonly deployed on OpenWrt gateways.
-
In terms of a gateway participating in some cloud packet interchange scheme, it’s good to remember that gateways tend to be far less physically secure than cloud machines, and are out on the big bad Internet rather than on data center’s private and peering interconnect. What all of that means is that a gateway should probably interact with your cloud only through a narrow and guarded door. It’s from the ingest server that you then start routing things on whatever fun internal scheme you want to use, to servers inside the fence which aren’t even routable from the Internet. Think of gateways a lot like web browsers as being largely external to data infrastructure. And just as with field-deployed IoT devices in general, any client trust tokens or keys you have in gateways should be unique to that box, not common across all of your system or fleet of ownership, such that if someone steals one gateway and starts abusing its keys, you can just cut invalidate that gateway’s keys server side and cut it off while everything else keeps running.