VeilNet

Edge and IoT Devices

Connect devices behind NAT on a remote site to a cloud collector, with one site node as the subnet router for devices that cannot run conflux.

Needs
A cloud VM for the collector and a Linux node on the site, each with root access and outbound internet access
Uses
conflux up, with --subnet on the site node

Before and After VeilNet

Use this setup when devices on a remote site are behind NAT and need to reach a collector in the cloud, without port forwarding or a VPN gateway.

Today, remote devices reach the cloud through a VPN gateway or a public API. They use MQTT over TLS with ECDH and ECDSA, and a quantum computer can break both.

With VeilNet, the collector, a site node and any device that can run conflux join the overlay. They get through the site's NAT themselves, and relay traffic for each other when they cannot. The collector reaches the other devices through the site node, which acts as their subnet router. No port is forwarded at the site.

Today and with VeilNetEdge & IoT

Today, MQTT over TLS, ECDH and ECDSA protect these links. A quantum computer can break all of them. With VeilNet, ML-DSA-87, ML-KEM-1024 and AES-256-GCM protect every link.

In the drawing, the sensor relays traffic for the camera and the PLC. Which machine relays for which depends on the network. Machines use a direct route first, and a relay only when no direct route exists.

Connecting the Site

0 of 6 done

  1. Follow Installation on the collector, the site node and any device that runs Linux on amd64 or arm64. The site node must be on the device network, which is 192.168.50.0/24 in this guide. The site needs no port forwarding.

On a sovereign network, the guardian commissions each machine and issues its manifest. Install it with sudo conflux enrol --manifest FILE, then run conflux up without --taint, because the credential carries the taints. The manifest's bootstrap list names your organisation's own publicly reachable bootstrap nodes. See Joining a sovereign network.

Verifying the Setup

On the collector, subscribe to the site's topics. You should see the sensor's reading arrive:

collector
$ mosquitto_sub -h 10.128.0.1 -u collector -P 'change-me' -t 'site/#' -v
site/temp 21.5

Then run sudo conflux routes on the collector. You should see the device network accepted from the site node:

collector
$ sudo conflux routes
NETWORK                                     VIA          STATE     WHY
10.128.0.1/32 (64:ff9b:1::a80:1/128)        -            served    -
10.128.0.10/32 (64:ff9b:1::a80:a/128)       n7o4v43imp   accepted  -
10.128.0.11/32 (64:ff9b:1::a80:b/128)       sqxezyex3r   accepted  -
192.168.50.0/24 (64:ff9b:1::c0a8:3200/120)  n7o4v43imp   accepted  -

To see how traffic reaches the site node, run sudo conflux route -to with the node's full AnchorID, from its anchor row. It prints direct, or relayed -> followed by the relays. To try to make a relayed route direct, run sudo conflux punch -to:

collector
$ sudo conflux route -to anchorn7o4v43impflvfupxqmb2y2nyrvd7rxinfrpyz43tbic367aez54
direct
$ sudo conflux punch -to anchorn7o4v43impflvfupxqmb2y2nyrvd7rxinfrpyz43tbic367aez54
the path is now direct

Reference

Anchor protocolDiscovery and NAT TraversalBootstrap, peer discovery, NAT traversal and relays.ConfluxSubnets, Exits and UplinkHow to forward a device network, and what the host needs.Anchor protocolSubnet Routers and ExitsHow routes are advertised and accepted, and how flows are shared.GuideSerial LinksA site with no IP network to the collector at all.