v2.1.0

Dragon Fruit Relay v2.1.0

Dragon Fruit Relay v2.1.0 is a major expansion over v2.0.2. The existing route-based IKEv2/IPsec + Linux XFRM foundation remains, while DFR now includes its own standalone management, policy, Client lifecycle and recovery plane.

Highlights

• Standalone Egress Hub Server and Ingress Client product model
• Authoritative SQLite Server registry
• One-time DFR1 enrollment tokens
• Authenticated CONTROL/1 management through the encrypted XFRM path
• Native subscriptions, quota, expiration and suspension
• Current-period and lifetime traffic accounting
• Per-connection upload/download speed limits and Server-wide shaping policy
• Public IPv4 and FQDN Server endpoints
• Managed endpoint synchronization, migration and drift reconciliation
• Transactional managed configuration with verification and rollback
• Server-managed signed Client software distribution
• STAGED / CANARY / STABLE / REVOKED Client release lifecycle
• AUTO / MANUAL / PINNED per-connection software policy
• Verified manual, automatic and rescue backups
• Fleet monitoring and detailed connection dossiers
• Improved Server and Client terminal workflows
• Debian 12 release-equivalent CI with exact extracted-ZIP re-testing
• Signed release-tag enforcement, SHA256SUMS and artifact attestations

v2.0.2 -> v2.1.0

Capability	v2.0.2	v2.1.0
Route-based IKEv2/IPsec with Linux XFRM	✅	✅
Multi-connection Egress Hub	✅	✅
Custom UDP transport	✅	✅
Automatic /30 tunnel allocation	✅	✅
Managed routing, forwarding, NAT and DNS	✅	✅
Public IPv4 Server endpoint	✅	✅
Standalone DFR product lineage	❌	✅
Authoritative SQLite Server registry	❌	✅
One-time DFR1 enrollment	❌	✅
CONTROL/1 management plane	❌	✅
Native subscriptions, quota, expiry and suspension	❌	✅
Native current-period and lifetime accounting	❌	✅
Per-connection speed policy	❌	✅
Server-wide traffic shaping	❌	✅
Client presence and convergence reporting	❌	✅
FQDN Server endpoint	❌	✅
Managed endpoint migration	❌	✅
Endpoint drift reconciliation	❌	✅
Transactional managed configuration	❌	✅
Signed managed Client software	❌	✅
STAGED / CANARY / STABLE / REVOKED release lifecycle	❌	✅
AUTO / MANUAL / PINNED software policy	❌	✅
Verified portable Server backups	❌	✅
Manual, automatic and rescue backup workflows	❌	✅
Zero-connection Server as a valid state	❌	✅
Fleet summaries and detailed connection dossiers	❌	✅
Exact extracted release ZIP re-test	❌	✅
Signed-tag release gate and artifact attestation	❌	✅

Capabilities marked ❌ under v2.0.2 were not native DFR capabilities in that release. Some could be handled independently by application-layer software such as Xray/3x-ui.

Standalone product lineage

v2.1.0 establishes the standalone Dragon Fruit Relay product lineage with explicit product and schema identity.

• Clean registry_schema=1 Server database contract
• Explicit standalone lineage markers in registry and managed configuration
• One installer for Egress Hub Server and Ingress Client
• Role-preserving standalone DFR-to-DFR upgrades
• Unmarked pre-lineage installations are rejected rather than guessed, imported or silently converted

This boundary is deliberate and provides a clean foundation for future DFR-to-DFR upgrades.

Server registry and fleet management

The Egress Hub now owns authoritative state for every managed connection.

Each connection has its own identity, PSK, custom UDP transport, XFRM interface, /30 tunnel allocation, strongSwan runtime, VICI socket, service and policy state.

Additional operational improvements include:

• zero-connection Egress Hub as a valid initialized state
• fleet summaries
• Client presence, health and convergence state
• detailed connection dossier
• isolated Server-side connection removal

DFR1 enrollment and CONTROL/1

v2.1.0 introduces formal enrollment and management protocols.

DFR1 enrollment tokens carry the information required to establish the managed Client connection, including Server endpoint, custom UDP transport, connection identity, tunnel allocation and management listeners.

CONTROL/1 is authenticated per connection and runs through the encrypted XFRM path. It carries managed configuration, health state, endpoint changes, management actions and Client software instructions.

Native subscriptions, accounting and speed policy

Per connection, the Egress Hub can now manage:

• quota
• expiration
• suspension/resume state
• upload speed limit
• download speed limit
• current-period traffic usage
• lifetime traffic counters

Server-wide traffic shaping policy is also available.

These controls are native to DFR and no longer require an external application layer.

IPv4 and FQDN endpoint management

The authoritative Egress endpoint can be either a public IPv4 address or an FQDN.

Supported transitions:

IPv4 -> IPv4
IPv4 -> FQDN
FQDN -> IPv4
FQDN -> FQDN

Endpoint changes are synchronized through CONTROL/1. DFR retains previous endpoint state while Clients converge and requires explicit completion before retiring that retained state.

Endpoint drift can also be detected and reconciled outside an active migration.

Managed Client software releases

The Egress Hub can distribute and control signed Ingress Client releases.

Release lifecycle:

STAGED -> CANARY -> STABLE
                    REVOKED

Per-connection software policy:

AUTO
MANUAL
PINNED

Fresh v2.1.0 Servers verify their exact bundled Ingress Client and publish it as STABLE. New connections default to AUTO/LATEST.

Managed deployments verify release identity and integrity before installation and retain rollback/recovery paths for failed updates.

Backups, restore and recovery

v2.1.0 adds verified Server backup and restore workflows.

• manual backups
• automatic backups
• rescue backups
• manifest and SHA-256 verification
• registry validation
• required signing/release metadata capture
• restore integrity checks

Client setup also records original host state for DFR-owned integration points so removal and recovery can restore those changes safely.

Reliability and release hardening

v2.1.0 adds additional failure handling and validation:

• fail-fast Server initialization and Client setup transactions
• rollback when an inner configuration step fails
• safe recovery for an interrupted empty standalone registry
• refusal of destructive recovery when connection rows already exist
• exact schema contract tests
• exact bundled Client integrity verification
• shell, generated Bash and embedded Python validation
• exact extracted release ZIP re-test
• signed release-tag enforcement
• published SHA256SUMS
• GitHub artifact attestations
• release-equivalent Debian 12 validation

UI and operations

The terminal interface retains the established DFR workflow while exposing the new management state more clearly.

• detailed Server Connection Overview
• authoritative Subscription & Traffic section
• compact Client Monitoring summary
• dedicated detailed Client status and managed-control workspaces
• clearer separation of diagnostics, software and configuration state
• consistent Refresh, Navigate, Back and Exit behavior
• streamlined fresh Client enrollment confirmation

Release assets

• dragon-fruit-relay-2.1.0.zip
• SHA256SUMS

The release archive is built and tested in Debian 12, then the exact extracted ZIP is tested again before publication.

Verification

Release tags are signed. The release workflow also publishes SHA-256 checksums and GitHub artifact attestations.

See docs/RELEASE-VERIFICATION.md in the repository for verification instructions.

---

Full Changelog: v2.0.2...v2.1.0

v2.0.2

Dragon Fruit Relay v2.0.2

Dragon Fruit Relay 2.0.2 introduces a custom-port-only connection model and fixes important interface, cleanup, upgrade, and strongSwan runtime issues discovered in version 2.0.1.

Highlights

• Uses one dedicated custom UDP port per connection.
• Removes standard UDP 500 and UDP 4500 transport support.
• Uses managed dfrNNNN XFRM interfaces for all new connections.
• Introduces pairing-token version 6.
• Supports conversion of compatible custom-port version 5 tokens.
• Removes legacy xfrm* configurations with a warning to recreate the connection.
• Starts tunnel allocation from 10.10.0.0/30.

Fixed

• Fixed stale dfrNNNN interfaces remaining after failed connection creation.
• Fixed incomplete VICI socket and runtime cleanup.
• Fixed profile rollback losing the allocated XFRM interface information.
• Fixed egress swanctl runtime failures caused by the previous symbolic-link layout.
• Replaced managed swanctl configuration and credential links with canonical files and directories.
• Improved cleanup of abandoned Dragon Fruit Relay interfaces and runtime files.
• Added automatic repair for compatible version 2.0.1 hub profiles.
• Added residual cleanup and complete uninstall options before initial configuration.

Transport model

Each connection uses one dedicated UDP port for tunnel establishment and encrypted relay traffic.

New profiles no longer use UDP 500 or UDP 4500.

Interface model

New connections use deterministic managed interfaces:

dfr0001 — XFRM ID 1001
dfr0002 — XFRM ID 1002
dfr0003 — XFRM ID 1003

Legacy xfrm* interface configurations are no longer supported and must be recreated.

Tunnel allocation

New tunnel networks are allocated in order:

10.10.0.0/30
10.10.0.4/30
10.10.0.8/30

The first connection uses:

Ingress: 10.10.0.1
Egress:  10.10.0.2

Pairing tokens

Dragon Fruit Relay 2.0.2 generates pairing-token version 6.

Compatible version 5 tokens using a custom UDP port and a valid dfrNNNN connection can be converted during import.

The following designs are rejected:

• Token versions 1–4
• Standard UDP 500/4500 profiles
• Legacy xfrm* interfaces
• Invalid dfrNNNN interface and XFRM ID mappings

Upgrade notice

Compatible custom-port Dragon Fruit Relay 2.0.1 hub profiles are repaired automatically when the updated management script is launched.

Profiles using standard ports or legacy XFRM naming are removed with a warning and must be recreated.

Installation

bash <(curl -Ls https://raw.githubusercontent.com/ozimellow/dragon-fruit-relay/main/install.sh)

Verification

The release includes:

• Bash syntax validation
• Custom-port-only profile generation
• Token version 6 generation
• Compatible token version 5 conversion
• Failed-profile rollback cleanup
• Canonical swanctl runtime layout
• Managed orphan-interface cleanup
• Tunnel allocation beginning at 10.10.0.0/30

v2.0.1

Dragon Fruit Relay 2.0.1

This release changes the project license from the MIT License to the GNU General Public License v3.0 or later.

Changes

• Replaced the MIT License with GPL-3.0-or-later
• Updated SPDX license identifiers in install.sh and dragon-fruit-relay.sh
• Added copyright notices for the original author
• Updated the README license badge and license section
• Updated the project version to 2.0.1
• Updated the changelog and issue template

Runtime behavior

No networking, routing, DNS, strongSwan, XFRM, NAT, diagnostics, recovery, or 3x-ui companion behavior was changed in this release.

Installation

Run as root on a supported Debian system:

bash <(curl -Ls https://raw.githubusercontent.com/ozimellow/dragon-fruit-relay/main/install.sh)

After installation:

dragon-fruit-relay

Release files

• dragon-fruit-relay-2.0.1.zip
• dragon-fruit-relay-2.0.1.zip.sha256

Verify the archive

Linux:

sha256sum -c dragon-fruit-relay-2.0.1.zip.sha256

Windows PowerShell:

$actual = (Get-FileHash .\dragon-fruit-relay-2.0.1.zip -Algorithm SHA256).Hash.ToLower()
$expected = (Get-Content .\dragon-fruit-relay-2.0.1.zip.sha256).Split()[0].ToLower()
$actual -eq $expected

Expected result:

True

License note

Version 2.0.0 remains available under the MIT License. Version 2.0.1 and later are released under GPL-3.0-or-later.

v2.0.0

Dragon Fruit Relay 2.0.0

First public release of Dragon Fruit Relay.

Dragon Fruit Relay provides managed, route-based IKEv2/IPsec networking for Debian using strongSwan, Linux XFRM interfaces, policy routing, systemd, and iptables.

Highlights

• Multi-connection egress hub
• Independent ingress connection profiles
• Pairing-token based setup
• Dedicated strongSwan process and VICI socket per egress connection
• Route-based Linux XFRM interfaces
• Automatic IPv4 /30 tunnel allocation
• Policy routing, forwarding, and source NAT
• Managed DNS with local fallback
• Health checks, diagnostics, repair, rollback, and removal
• Live DNS and tunnel traffic capture
• Optional deployment alongside 3x-ui/Xray

Dragon Fruit Relay is independent of 3x-ui and Xray. It does not install, modify, or bundle either project.

Installation

Run as root on a supported Debian system:

bash <(curl -Ls https://raw.githubusercontent.com/ozimellow/dragon-fruit-relay/main/install.sh)

After installation:

dragon-fruit-relay

Release files

• dragon-fruit-relay-2.0.0.zip — complete release archive
• dragon-fruit-relay-2.0.0.zip.sha256 — SHA-256 checksum

Verify the archive

Linux:

sha256sum -c dragon-fruit-relay-2.0.0.zip.sha256

Windows PowerShell:

$actual = (Get-FileHash .\dragon-fruit-relay-2.0.0.zip -Algorithm SHA256).Hash.ToLower()
$expected = (Get-Content .\dragon-fruit-relay-2.0.0.zip.sha256).Split()[0].ToLower()
$actual -eq $expected

Expected result:

True

Requirements

• Debian with systemd
• Root access
• IPv4 connectivity
• A reachable egress server
• UDP 500 and 4500, or a configured custom UDP port

See the repository documentation for installation, architecture, operations, troubleshooting, removal, and optional use alongside 3x-ui/Xray.