Full tunnel
All eligible traffic is carried through the VPN interface. Simpler to reason about, and usually the default expectation for a consumer-facing connectivity product.
VPN Development
VPN Development from Client Application to Network Integration
Southwest Network Corporation provides engineering for VPN and network-connectivity products, including client applications, tunnel integration, routing policy, control-plane systems, network resource integration, multi-platform release engineering, and ongoing technical iteration.
Scope
What we build
A VPN product is not one piece of software. It is a client application on every target platform, a tunnel integration layer, a routing policy, a control plane the clients depend on, gateway integration, and a release process that keeps all of it shippable.
01
Cross-platform Client Applications
Client applications for Windows, macOS, iOS, Android, Linux, and router environments where the target firmware allows it. Includes the interface work around connect and disconnect, connection state, region or route choices, and update handling.
- Desktop, mobile, and router client targets
- Connection state and error presentation
- Region / route selection interfaces
- Update and version handling
02
Tunnel & Protocol Integration
Integration of a tunnel protocol behind an adapter layer, so session establishment, reconnect behaviour, and platform networking integration are handled consistently across targets. WireGuard, OpenVPN, and IKEv2 appear here only as common integration options.
- Protocol adapter layer
- Session establishment and teardown
- Reconnect and state recovery
- Platform networking integration
03
Routing & Traffic Policy
Design and implementation of which traffic uses the tunnel: full tunnel or split tunnel, included and excluded routes, and per-app or destination-based rules where the operating system exposes them. DNS and routing configuration are part of the platform integration work.
- Full tunnel vs split tunnel behaviour
- Include / exclude route sets
- Per-app or destination rules where supported
- DNS and interface configuration
04
Control Plane & Account Systems
The product backend that clients depend on: authentication and account lifecycle, device registration, configuration delivery, a directory of available regions and resources, plan or subscription state integration, and client version and configuration management.
- Authentication and account lifecycle
- Device and client-version registration
- Configuration and resource directory delivery
- Plan / subscription state integration
05
Network Resource & Gateway Integration
Integration work at the gateway and service-endpoint layer: how endpoints are registered and organised by region, how health and status signals are collected, how configuration is rolled out, and how traffic paths are designed.
- Gateway / service endpoint integration
- Health and status signalling
- Configuration rollout
- Regional resource organisation
06
Observability, QA & Release Engineering
Connection state and error telemetry, log and diagnostic design, automated build and release pipelines, cross-platform compatibility testing, crash and error review, and a repeatable update workflow.
- Connection state / error telemetry
- Log and diagnostic design
- Automated build and release pipeline
- Cross-platform compatibility testing
Architecture
VPN product architecture
Client, tunnel, control plane, and gateway responsibilities are separated before implementation starts, so a change in one layer does not silently become a change in another.
Layer 01
Client Applications
Desktop, mobile, and router clients that authenticate, fetch configuration, present connection options, and report state.
Layer 02
Authentication & Account API
User, account, and session lifecycle, plus device and client-version registration.
Layer 03
Configuration & Resource Directory
Distribution of client configuration and metadata about available regions and resources, together with plan or subscription state integration.
Layer 04
Tunnel / Gateway Layer
The data-path layer the client connects to, integrated by region with health metadata and staged configuration rollout.
Layer 05
Observability & Operations
Connection state and error signals, service health metadata, diagnostics, and update or configuration rollout workflows.
Illustrative architecture · no live data
This is a conceptual VPN product architecture used to explain development scope. It does not disclose Rabbit Fast's internal architecture.
Platforms
Cross-platform client engineering
Each operating system exposes VPN functionality through its own APIs and its own constraints. The matrix below describes the engineering context we work in per platform.
Android
Android VpnService
Android exposes VpnService, which lets an application establish a virtual network interface, configure addresses and routes, receive outgoing IP packets, and inject received packets back into the networking stack. App-level allow and deny routing is configured through VpnService.Builder.
- Virtual interface setup
- Route configuration
- VPN lifecycle & user consent
- Per-app allow / deny
iOS & macOS
Network Extension
Apple platforms provide Personal VPN for the built-in IPsec/IKEv2 configurations and Packet Tunnel Provider for packet-oriented custom protocols. A packet tunnel provider works through a virtual interface and can set included and excluded routes, DNS, a virtual IP, and MTU, including per-app VPN contexts.
- Packet Tunnel Provider
- Personal VPN / IKEv2
- Included & excluded routes
- DNS, virtual IP, MTU
Windows
Routing policy & profiles
On Windows, an important design choice is split tunnel versus force tunnel. Routing policy decides which traffic uses the VPN interface and which stays on the physical interface, and profile configuration determines how that behaviour is applied.
- Split vs force tunnel
- Route policy in the profile
- Client integration
- Interface behaviour
Linux
Tunnel & service integration
Linux work covers tunnel and protocol integration alongside routing table and DNS handling, service lifecycle under the init system in use, and packaging for the distributions a project needs to target.
- Tunnel / protocol integration
- Routing & DNS handling
- Service lifecycle
- Packaging
Routers
Configuration-oriented integration
Router work is configuration-oriented rather than application-oriented, and depends on what the target firmware supports. It is scoped per project against the specific device and firmware requirements.
- Firmware-dependent scope
- Configuration templates
- Gateway-side behaviour
- Device coverage review
This section describes company development capability and engineering scope. It does not state which platform APIs or implementations are used inside Rabbit Fast.
Tunnel & protocol
Protocol integration options
Protocol choice is a project decision, not a slogan. The options below are the families most often evaluated, each with different trade-offs in transport, platform fit, and long-term maintenance.
WireGuard
Option 01A modern VPN tunnel protocol using Cryptokey Routing over UDP transport. Frequently considered where a compact, UDP-oriented tunnel suits the deployment.
wireguard.comOpenVPN
Option 02A mature open-source VPN platform and protocol family built on SSL/TLS, with flexible client/server deployment and both TCP and UDP tunnelling.
openvpn.netIKEv2 / platform-native VPN
Option 03Relevant where using the operating system's built-in VPN configuration is the right fit, for example Apple's Personal VPN path or managed profiles on Windows.
developer.apple.comExisting or customer-supplied protocol
Option 04An existing protocol or tunnel architecture supplied by the customer can be evaluated and integrated behind the client adapter layer. We do not claim to have authored a proprietary VPN protocol.
Protocol examples describe common VPN engineering options and do not state which protocol Rabbit Fast uses. Protocol selection depends on project requirements, target platforms, deployment environment, and maintenance constraints.
Routing
Routing & traffic policy
Deciding which traffic uses the tunnel is one of the defining behaviours of a VPN product, and one of the most common sources of inconsistent behaviour between platforms.
Routing decisionIllustrative · no live data
Split tunnel
Selected traffic is carried through the VPN interface while everything else stays on the physical interface. Requires a clear rule set and predictable behaviour when rules do not match.
Include / exclude rules
Route sets decide which destinations are inside the tunnel. Apple's packet tunnel configuration and Windows routing policy both express this as included and excluded routes.
Per-app & destination strategies
Where the operating system exposes it — for example app allow and deny lists on Android — routing can be scoped per application rather than per destination alone.
Control plane
Control-plane, account, and gateway integration
Behind the client sits the product backend: who the user is, which devices are registered, what configuration each client receives, which regions and resources exist, and what plan state applies.
Account & session lifecycle
Sign-in, session handling, account state, and device or client-version registration.
Configuration delivery
Client configuration and resource metadata delivered per device, with staged rollout of changes.
Resource directory
A directory of available regions and connection resources that clients read at runtime.
Plan & subscription state
Integration of plan or subscription state so client entitlements follow the commercial model.
Gateway integration
Registration, regional grouping, and health or status signalling for service endpoints in the data path.
Operations surface
Service health metadata, diagnostics, and controlled configuration and version rollout.
This is a conceptual VPN product architecture used to explain development scope. It does not disclose Rabbit Fast's internal architecture. Specific providers, databases, payment processors, and infrastructure arrangements are project-dependent and are not asserted here.
Quality
Observability, diagnostics & release engineering
A connectivity product is judged on how it behaves when a network misbehaves. That makes state reporting, diagnostics, and a repeatable release process part of the engineering work rather than an afterthought.
01
Connection state telemetry
Connection and error state reported in a form that can be acted on during support and development.
02
Log & diagnostic design
Diagnostic output designed for troubleshooting. No privacy or retention guarantees are asserted here.
03
Build & release pipeline
Automated builds and a repeatable release path for each target platform and distribution channel.
04
Compatibility & crash review
Cross-platform compatibility testing plus crash and error review feeding the next iteration.
Lifecycle
How a VPN product engineering engagement runs
Requirements, architecture, implementation, integration, release, and iteration — each stage produces a written record so the product stays maintainable after handover.
- 01
Requirements
Target platforms, routing behaviour, protocol constraints, and product expectations are recorded in writing.
- 02
Architecture
Client, tunnel, control-plane, and gateway responsibilities are defined before implementation begins.
- 03
Implementation
Client applications, adapter layers, routing policy, and backend services are built in agreed stages.
- 04
Integration & QA
Cross-platform behaviour, reconnect handling, and routing rules are tested against the defined requirements.
- 05
Release
Builds are produced through an automated pipeline and distributed through the channels each platform requires.
- 06
Iteration
Telemetry, error review, and change records feed the next round of product engineering work.
Reference product
Rabbit Fast — a company-operated reference product
Rabbit Fast is operated by Southwest Network Corporation as a practical example of multi-platform VPN and connectivity productization: one product across desktop, mobile, and router environments, with a consistent connection workflow, plan structure, and support channel.
Cross-platform product delivery
One product published across Windows, macOS, iOS, Android, Linux, and router environments.
Connectivity product UX
A consistent connection workflow: install, sign in, choose a connection option, connect.
Routing-oriented product design
Route and connection options surfaced to the user rather than hidden behind a single fixed path.
Product lifecycle & support
A product website, client distribution, plan structure, and an ongoing customer-support channel.
Protocol internals, network topology, provider relationships, node counts, security configuration, and other operational details are not published on this corporate website.
Engagement models
Ways an engagement can be scoped
Scope, deliverables, platform coverage, and responsibilities are agreed in writing before work begins. No pricing, timelines, or client references are published here.
- 01
Full product development
A VPN or connectivity product taken from architecture through clients, control plane, and release engineering.
- 02
Existing product modernization
Reworking an existing VPN product: platform coverage, client architecture, routing behaviour, or release process.
- 03
Cross-platform client development
Client applications for specific target platforms against an existing protocol and backend.
- 04
Protocol / tunnel integration
Integration of an open or customer-supplied tunnel protocol behind a client adapter layer.
- 05
Routing & split-tunnel engineering
Design and implementation of routing policy, include and exclude rules, and per-app strategies where supported.
- 06
Control-plane engineering
Authentication, account lifecycle, configuration delivery, resource directory, and plan-state integration.
- 07
Maintenance & release engineering
Ongoing build, test, release, and diagnostic work for a product already in the market.
FAQ
VPN development questions
Answers describe engineering scope and are deliberately conservative about anything that would depend on a specific project.
What parts of a VPN product can be developed?+
Client applications, the tunnel and protocol adapter layer, routing and traffic policy, the control plane and account systems, gateway and network resource integration, and the observability, QA, and release pipeline. An engagement can cover all of it or a single layer.
Can an existing protocol or backend be integrated?+
Yes. An existing or customer-supplied protocol, tunnel implementation, or backend can be evaluated and integrated behind the client adapter layer, so the client work does not require replacing what already runs.
Which platforms can be targeted?+
Windows, macOS, iOS, Android, Linux, and router environments where the target firmware supports the required configuration. Platform coverage is agreed per project.
How are split-tunnel requirements handled?+
Split tunnel is treated as a routing-policy design task: which routes are included or excluded, whether rules are per destination or per application, and what happens when no rule matches. What is achievable depends on the APIs each operating system exposes.
Do you provide a proprietary VPN protocol?+
No. We do not claim a proprietary protocol. Protocol selection is project-specific: common open protocol families such as WireGuard or OpenVPN, platform-native options such as IKEv2, or a protocol the customer already owns can be evaluated and integrated.
Is Rabbit Fast a customer project?+
No. Rabbit Fast is a company-operated reference product of Southwest Network Corporation, not a client engagement. It is published as a practical example of multi-platform VPN and connectivity productization.
What is not published on this website?+
Protocol internals, network topology, provider relationships, node counts, security configuration, and other operational details are not published on this corporate website.
Corporate disclosure
Engineering work described on this page is performed by Southwest Network Corporation, a profit corporation registered in Wyoming, United States under Filing ID 2025-001705820. Corporate registration does not represent licensing or authorization for regulated telecommunications activities, and no owned backbone, data centre, carrier relationship, or security certification is claimed. Full registration details are on the Company Information page.