CloudAddress -- Overview v1.0.0

Applies to Cloud Spectra 1.0.0. CloudAddress is one of the four relay modes of Cloud Spectra Gateway; the other three have their own tabs above.

What CloudAddress is

CloudAddress gives one device -- a laptop, a desktop, a home server, a phone -- a public IP address from your own cloud account. A small Cloud Spectra relay runs in that account and holds the address. Your device connects to the relay over an encrypted WireGuard tunnel and wears the address: connections made to the address are delivered to your device, and traffic your device sends through the tunnel leaves the cloud from it.

The relay's own dashboard describes the mode in one line: "One public address, transferred to one device. The device wears it; nothing is NAT'd." The dashboard's mode picker labels it Cloud IP, and a running CloudAddress relay reports itself as CloudAddress Relay (1:1 address transfer). Its configuration value is cloud_address (the older spelling cloud_ip is still accepted and means the same thing).

CloudAddress is not a separate product. The relay is a feature of Cloud Spectra Gateway: it uses the same licence key, the same subscription and the same per-vCPU meter as everything else in the product. You create and manage CloudAddress relays with the free cloudspectra_relay_client command-line client, which provisions the relay in your cloud account using your own cloud credentials.

The problem it solves

• A stable public IP for a device whose own address changes or is shared. Home and mobile connections often sit behind carrier-grade NAT, or change address whenever the router restarts. A device wearing a CloudAddress answers on a fixed address held in your cloud account instead.
• One address for allow-lists. Partners, SaaS admin consoles and corporate firewalls can allow-list one address from your cloud account rather than a list of home, office and hotel addresses. With a full tunnel, everything the device sends leaves from that address.
• Hosting behind NAT. Inbound connections to the address are delivered to your device with the visitor's address intact, so a service on a laptop or home server is reachable on a real public IP -- on the ports you open in the relay's cloud firewall.
• A foothold in your cloud network. On Azure, Google Cloud and Oracle Cloud the device wears the relay's private address in its cloud network, so the device reaches that network's private addresses through the tunnel, and a device that is not itself a cloud instance reads the relay's instance metadata at 169.254.169.254.
• Moving the address between machines. The address belongs to the relay, not to the device. Hand it to another machine with a fresh enrolment token and an explicit takeover, and every allow-list and DNS record that names the address follows it.

Choosing a relay mode

The relay has four modes. Each is described below in the words the relay's dashboard uses for it.

CloudAddress is deliberately one address for one device at a time. If several devices need to share an address at once, that is CloudVpn; if you need capacity spread across a fleet of relays, that is CloudConnector. The product refuses a CloudAddress configuration that asks for a load balancer or a fleet, because there would be no single address to hand over.

How it works

flowchart LR
    DEV["Your device
laptop / server / phone
wears the relay's address"]
    subgraph ACCT["Your cloud account"]
        RELAY["Cloud Spectra relay
public IP + private VPC address"]
        VPC["Your cloud network
(private addresses)"]
    end
    NET["The internet"]
    DEV <-->|"WireGuard tunnel
UDP 28302"| RELAY
    RELAY <-->|"traffic to and from
the worn address"| NET
    RELAY <--> VPC
    style ACCT fill:#eef2ff,stroke:#6366f1,color:#312e81
    style RELAY fill:#d1fae5,stroke:#10b981,color:#065f46
    style DEV fill:#dbeafe,stroke:#3b82f6,color:#1e3a8a
    style NET fill:#fef3c7,stroke:#f59e0b,color:#92400e

1. Provision. cloudspectra_relay_client setup (or create) calls your cloud's API with your credentials and builds the relay: a small Linux instance, a network to put it in (your account's default network where the cloud has one, otherwise a new isolated one), a firewall, and -- on every supported cloud except DigitalOcean -- a reserved public IPv4 address. Every object is tagged with your project and relay name. There is no Cloud Spectra-side inventory: list, describe and destroy read those tags, so they work from any machine that holds the cloud credentials.
2. First boot. The instance boots a stock image from your cloud's own catalogue (Debian 13 or Ubuntu 24.04 LTS, depending on the cloud), installs the signed Cloud Spectra package and Cloud Spectra's hardened kernel, and reboots into it. On Oracle Cloud the CLI may instead import the published relay image into your tenancy once per region and release. The relay then presents your licence key to the Cloud Spectra control plane, which delivers its signed datapath.
3. Enrol. Your device generates its own WireGuard key pair, and sends only the public key, with a single-use enrolment token, to the relay's enrolment API on TCP port 28300. The relay answers with the tunnel configuration. setup mints the token for you; for other devices you mint one on the relay's dashboard.
4. Wear. The device raises the tunnel and wears the relay's identity address. On Azure, Google Cloud and Oracle Cloud that is the relay's private address in its cloud network, and the cloud's own one-to-one mapping between the relay's public IP and that private address carries the public IP with it. On DigitalOcean the public IPv4 sits directly on the relay's interface, and the device wears it as is. The relay itself translates nothing.
5. Carry traffic. By default the tunnel is split: only the relay's network range and (for an off-cloud device) its metadata address go through the relay, and inbound connections to the address reach the device. With --full-tunnel, all of the device's traffic leaves through the relay and its egress address becomes the relay's public IPv4.

Ports 28300-28349 on the address always stay with the relay: 28300 is the dashboard and enrolment API, 28301 is the relay's recovery SSH, and 28302-28349 carry the WireGuard tunnel. Every other port on the address belongs to your device.

Security in brief

• The relay runs in your cloud account; your tunnel traffic flows between your device, your relay and the internet, and does not pass through Cloud Spectra.
• The relay contacts the Cloud Spectra control plane to validate its licence, report the usage it is billed for, and obtain its signed datapath. A relay with no valid licence starts parked: its dashboard answers, and it forwards nothing.
• Your device's private WireGuard key is generated on the device and never leaves it. Enrolment tokens are single-use and short-lived (two minutes by default).
• The relay's dashboard is password-protected; the CLI seeds only a bcrypt hash of the password to the relay.

See the security model in the User Guide for the full picture.

Supported clouds and address families

Amazon Web Services is not a supported CloudAddress target in 1.0.0. The client accepts --provider aws, but a relay created that way in your AWS account does not start. See Known limitations.

Regions. Any region of the cloud that your account can use and that offers the instance type. Pass --region; without it the CLI uses the region your cloud tooling is configured for (for example ~/.oci/config on Oracle Cloud).

Address families. By default the relay is reached over IPv4. With --addr ipv6 the relay is reached on its IPv6 address and gets no public IPv4 at all, so no public IPv4 is billed; your device then needs IPv6 connectivity, and a full tunnel is refused because there is no public IPv4 to leave from. When a relay is reached over IPv4 and also holds a public IPv6 address, the device wears that IPv6 address as well. See IPv6.

Requirements

• A Cloud Spectra licence key (it begins CSTW1-), from your Cloud Spectra account.
• An account on a supported cloud, with credentials allowed to create instances, networks, firewalls and public addresses. The client can create a least-privilege identity for itself with cloudspectra_relay_client login.
• A device running one of:
  • Linux on x86_64 or arm64 with kernel 5.10 or newer -- a .deb package for Debian and Ubuntu, or the standalone binary elsewhere;
  • macOS 13 or newer, Apple silicon or Intel -- a .pkg installer;
  • Windows on x64 or ARM64 -- an .msi installer;
  • iOS or Android -- the stock WireGuard app, enrolled by QR code from the relay's dashboard or the CLI. No Cloud Spectra app is needed.
• Administrator rights on the device (sudo, or an elevated prompt on Windows): raising the tunnel creates a network interface and changes routes.
• Network reachability from the device to the relay on UDP 28302 (the tunnel; up to 28349 with bonding) and TCP 28300 (enrolment).

Pricing

A CloudAddress relay has two bills, and neither depends on how much traffic you send through it:

• Your cloud provider bills the relay's instance, disk, public address and data transfer to your cloud account, at its own prices.
• Cloud Spectra bills the relay's vCPU-hours on your subscription: $10 per vCPU per month on the Developer plan and $30 per vCPU per month on the Enterprise plan, metered hourly. Only the first 64 vCPUs of an instance count, and the second one is free -- so an instance bills at most 63 vCPUs, and 1- and 2-vCPU instances cost the same. Clients are free -- you pay for the relay, not for devices.

The Developer plan covers development, evaluation, personal use, and CloudAddress for business: a business that needs a static address may run CloudAddress in production on it. Its limit is 16 vCPUs per account across all your relays (counted on the instances' actual vCPUs); a relay that would take the account over the limit is parked until capacity frees up. The Enterprise plan has no account limit, a 4-vCPU minimum per instance (smaller relays are refused at registration), and adds a response-time SLA, SSO and exported audit.

Your first 30 days are free, once per account, and a month under $1 is not invoiced. Pausing a relay (pause) stops its software meter while keeping its addresses and disk. cloudspectra_relay_client list-instance-types prints instance types with their cloud price and their monthly Cloud Spectra cost. Full details are on the Pricing page.

Limits at a glance

• One device at a time. A relay has one wearer. A second device can take the address only with an explicit --takeover, which disconnects the first.
• One relay, one address. CloudAddress does not spread across a fleet or sit behind a load balancer; run more relays for more addresses.
• Ports 28300-28349 on the address always belong to the relay.
• Inbound needs an open port. The relay's cloud firewall admits TCP 22 by default plus the relay's own ports; choose your ports with --open-port.
• A full tunnel needs a public IPv4, so it is refused on an IPv6-only (--addr ipv6) relay.
• DigitalOcean addresses do not survive a destroy; on Azure, Google Cloud and Oracle Cloud the address is kept for reuse.
• AWS is not supported for CloudAddress in 1.0.0.

The complete list is in Known limitations.