start-tunnel v1.3.0

What's Changed

Added

• Devices can request SNI hostname routes over UPnP, not only PCP. The
  tunnel's UPnP IGD now serves two Start9 vendor actions
  (X_START9_AddHostnameMapping / X_START9_DeleteHostnameMapping, advertised
  in its WANIPConnection:1 SCPD) that bind a hostname on a shared external
  port via SNI demultiplexing — the same capability the PCP HOSTNAME option
  provides. A device that reaches the tunnel over UPnP but not PCP (for
  example, UDP 5351 filtered by an intermediate device) previously kept its
  ordinary port forwards but silently lost SNI demux; StartOS now falls back to
  the vendor action automatically. Unlike standard UPnP mappings, these routes
  are always lease-bearing and expire if the device stops renewing them, so a
  vanished device can never squat a hostname against its legitimate owner.
  A hostname grant (over either protocol) is now also refused outright when
  the tunnel cannot bind the shared port's listener, instead of being
  acknowledged while routing nothing.

• Generated WireGuard configs identify their gateway as accepting inbound
  connections. Each config includes the # inbound: yes gateway marker while retaining its
  StartTunnel header for compatibility with older StartOS versions.

Fixed

• start-tunnel reaches a daemon that listens on a wildcard address. With no
  --tunnel, the CLI derives the daemon's address from tunnel-listen and
  authenticates with the local authcookie, which it sends only to a loopback
  address. A tunnel server binds 0.0.0.0 by nature, so the derived address was
  never loopback: the CLI skipped the token and then, having no local auth, fell
  through to dialling https://0.0.0.0 — a request that can't succeed. A wildcard
  listen address is now dialled over loopback, since binding every interface is not
  a destination.

• subnet <SUBNET> set-wan and subnet <SUBNET> set-ipv6 take the subnet
  once, from the parent subnet command. Both asked for it a second time
  after the subcommand name, and no invocation satisfied that — giving the
  subnet once failed argument parsing, giving it twice was rejected as a
  duplicate key — so neither command could be run at all. They now inherit the
  subnet the way add, remove and set-dns already did, matching the syntax
  the documentation shows.

• An automatic port forward that asks for a time limit now expires when that
  time runs out. A device requesting a timed UPnP mapping had it kept as
  though it were permanent, so a forward could outlive the app that asked for
  it — staying open until the tunnel was next restarted. Automatic ports are
  now lease-based as documented: one that stops being renewed is removed on its
  own. Devices that ask for a permanent mapping, which is what StartOS does,
  are unaffected.

• Third-party UPnP clients can now use the tunnel as a gateway. The device
  description didn't advertise the WANCommonInterfaceConfig service, and the
  tunnel answered none of the actions a client uses to check a gateway before
  using it (GetStatusInfo, GetConnectionTypeInfo, GetNATRSIPStatus) or to
  read a mapping back (GetSpecificPortMappingEntry,
  GetGenericPortMappingEntry). Software built on the common UPnP client
  library — which includes many torrent clients and consumer apps — therefore
  rejected the tunnel outright with "no valid UPnP Internet Gateway Device
  found", or created a mapping and then reported it as failed because it could
  not read it back. StartOS was unaffected; its client requires none of these.

Security

• The UPnP device description no longer identifies the tunnel to web
  pages. The description endpoint answered anyone who could reach it, and it
  names the product ("StartTunnel") plus a stable identifier derived from the
  tunnel's WireGuard key — so a malicious website could rebind its own domain
  to the gateway and read it from any tunneled phone or laptop's browser: a
  cross-site tracking beacon that re-identifies a visitor behind this tunnel
  from any network. All UPnP endpoints now refuse requests whose Host is not
  an IP address, which a real UPnP client always sends and a rebinding page
  never can. As defense-in-depth, actions that change port forwards must also
  be named in the SOAPAction header (every real client sends it; a
  cross-origin page can never attach it), so even a browser running on a
  device that has been granted automatic port forwarding cannot be used to
  drive forwards blind.

start-tunnel packages Checksums

SHA-256

bc5fb84a8298c32a2e5f2d39bf80e8f166e78468262f362188bfb9eee4057567  start-tunnel_1.3.0_amd64.deb
88b74862389b1108fc9e73f7acf6433322e51a60786b2739cf9e971b0a1f47e8  start-tunnel_1.3.0_arm64.deb
c4fb03ee81b7de62e760ed429f81a8c4ea7cff664595343de8f9c33f34833174  start-tunnel_1.3.0_riscv64.deb

BLAKE-3

88ed06bf2e40d6ee56083330289deb9f921cd82c6d22c72e00346e28975341fd  start-tunnel_1.3.0_amd64.deb
867141c070c7c6db756f9bfc9263df3fc8bdc5a178a25c7052c257d427d02ed6  start-tunnel_1.3.0_arm64.deb
e8950c7700ff5bf3d150f043e33dbc756506cefd52637bd7225710d9d384f4f5  start-tunnel_1.3.0_riscv64.deb