StartOS

What's Changed

Added

• HTTP→HTTPS redirects on port 80. StartTunnel now runs an HTTP→HTTPS redirect on port 80 of every public IPv4 it holds, so a plain http:// request to an exposed service is answered with a redirect to the same host over https:// instead of a connection error. These are on by default — every public IPv4 gets one on a fresh install and after an update — and reuse the same redirect handler the OS serves on its own TLS ports. Each address has a toggle in the HTTP Redirect (80 → 443) section of the Settings page (and start-tunnel http-redirect list / set-enabled <ip> [--enabled] on the CLI) to turn it off; your choice persists. A redirect and a port-80 forward are mutually exclusive and never both enabled: forwarding port 80 is rejected while the redirect is on (turn it off first), and enabling the redirect is rejected while port 80 is forwarded (delete the forward first). Port 80 is also never auto-forwarded — StartTunnel refuses PCP/UPnP requests to map it — and the Add published port dialog no longer offers to also forward 80 → 443. See the HTTP Redirects page in the docs.

• Per-subnet IPv6. A subnet can now carry a routed IPv6 prefix your VPS delegates, and every host on it — the tunnel and each device — gets one globally-routable /128 with its tunnel IPv4 embedded (prefix-network | tunnel-IPv4), so a device's address is stable and derivable from its IPv4 alone. Configure it per subnet with start-tunnel subnet <SUBNET> set-ipv6 --prefix <prefix> or the subnet's Add/Edit dialog (disable by omitting the prefix). Configuring per subnet lets a server with multiple disjoint allocations point different subnets at different prefixes. On the common single-/64 case the tunnel answers Neighbor Discovery for each device's address on the VPS network; device IPv6 is carried full-tunnel (AllowedIPs = ::/0) so replies return through the tunnel. Devices can make outbound IPv6 connections, and — on a device running a current StartOS (0.4.0-beta.10+) — accept unsolicited inbound connections too, so a service can be hosted over IPv6. The subnets and devices tables show the prefix and each device's computed address. See the IPv6 page in the docs.

• subnet … set-ipv6 validates the server can route the prefix. Because a device with an IPv6 assignment routes all its IPv6 full-tunnel (AllowedIPs = ::/0), a prefix delegated on a server without working IPv6 egress just blackholes. The command hard-errors (leaving the config unchanged) when the server has no IPv6 default route, and logs an actionable warning when the prefix is neither on-link on a WAN interface nor otherwise verifiable — so operators catch a misconfigured VPS at set-time instead of discovering dead IPv6 on their devices.

• Port-range forwarding. A manual port forward can now span a contiguous range of ports. Set "Number of Ports" in the Add published port dialog — or --count on start-tunnel port-forward add — to forward that many consecutive ports counting up from both the external and internal port. Ranges are plain port forwards and cannot be combined with SNI demux. (Automatic PCP PORT_SET range forwarding requested by connected devices was already supported; this exposes it to manually-added forwards.)

• IPv6 port forwarding (firewall pinholes). A port forward can now expose a device over IPv6, not just IPv4. Because each device has its own globally-routable address (its GUA — see the IPv6 page), an IPv6 forward is a firewall pinhole on [GUA]:port with no NAT, rather than a DNAT from a shared public IPv4. The Add published port dialog gained an IP Version selector (IPv4 / IPv6 / IPv4 + IPv6) so one dialog covers both stacks — the external/internal port fields apply to whichever you pick — and each published port's IP is the public IPv4 (v4) or the device's GUA (v6). Choosing an external port different from the internal one (e.g. the 80 → 443 redirect) turns the v6 side into a port-only translation on the same GUA. IPv6 requires the selected server's subnet to have a routed prefix; the dialog says so when it doesn't. Manage them from the CLI with start-tunnel pinhole add|remove|set-enabled|update-label. Connected StartOS servers open v6 pinholes automatically via PCP (including the 80 → 443 redirect) the same way they already do for IPv4, so hosting a service over IPv6 works end to end.

• Contextual help sidebar with per-screen guidance, linking out to the docs.

• Internationalization: a translatable UI with a language selector; English and Spanish included.

• Sortable columns on the Subnets, Devices, Published Ports, and DNS tables.

Changed

• Automatic (PCP) mappings now honor their lease. A forward, pinhole, or SNI route opened automatically by a connected device carries a finite lease that the device renews while it still wants the port. The tunnel now expires and tears down an automatic mapping whose device stops renewing it — because it went offline, rotated its key, or withdrew the exposure — instead of leaving a stale forward in place indefinitely. Manually-added forwards are unaffected and remain persistent.
• Admin actions retire a device's forwards immediately. Deleting a device or demoting it to a client now clears all of its forwards, SNI routes, and IPv6 pinholes (previously a deleted device's v6 pinholes could linger); disabling auto-publish for a device clears its automatic forwards while leaving any you added manually. Cleanup no longer waits for the lease to lapse.
• Renamed "Port Forwards" to "Published Ports" (and the device "Auto Port Forward" capability to "Auto-publish"); CLI/RPC unchanged.
• Relabeled the DNS "Name" column as "Hostname".

Fixed

• --version now reports StartTunnel's own version (1.1.0) instead of the StartOS
  platform version.

Documentation

• Expanded the Subnets and DNS Records pages, and renamed the Port Forwarding page to Published Ports.

start-tunnel packages Checksums

SHA-256

6fa2cd2c4e5b96d7d018406eb64058f446264c51235eee90ea910aab7b380aae  start-tunnel-1.1.0-65f1872_aarch64.deb
f625814150fbd7ce8a1f781de35d4411520630bd664fdac16602c492abab3f10  start-tunnel-1.1.0-65f1872_riscv64.deb
e908d1e33f23e58c196d8b2bae600ac6759dc5d4b7a06d1d8ce65bd6142ec20f  start-tunnel-1.1.0-65f1872_x86_64.deb
fdf043614f47012a9cdcf9579ea7bdcfa548b82c77914da24dc1d4c5acec5690  start-tunnel-1.1.0-ff941f2_aarch64.deb
0e3b60da0298fcf92d014bf54603a8e8ac9c206d28fa2492b929a64f1c346717  start-tunnel-1.1.0-ff941f2_riscv64.deb
34caadc156ba315e88d1ed5c27feba1b06dd3fe81b3406d011a1fc4c4309b046  start-tunnel-1.1.0-ff941f2_x86_64.deb

BLAKE-3

93d4e2baa0899fd2bcb2345c52f5858c526919f60daea750124462a277e9020d  start-tunnel-1.1.0-65f1872_aarch64.deb
abbeb47de6756d4ee31e5f01b0324fbc669b52cbff16f902f306df2023be0353  start-tunnel-1.1.0-65f1872_riscv64.deb
8c7c701203cf37eadc242af58341bbd899c947c678bb940ebb0ca1eb6c8ec64d  start-tunnel-1.1.0-65f1872_x86_64.deb
2cb529040d7708b148a11e3894edf6db3a6b82055d18688969e612bf0a28c032  start-tunnel-1.1.0-ff941f2_aarch64.deb
42b5c4e3a59e2615cc355637e2f0285668866c17698c6d924cd4ba6efb36184b  start-tunnel-1.1.0-ff941f2_riscv64.deb
b864ad7c1b72408ab84f0aee8107f9b81aeabaff74b2d2d9210349754f3409bf  start-tunnel-1.1.0-ff941f2_x86_64.deb