SBN Tunnel Security Architecture
This page describes the security architecture of SBN Tunnel and compares it, control by control, against a traditional network-layer VPN (IPsec / SSL-VPN). The summary position: SBN Tunnel provides the same encryption strength as a modern VPN, and a materially stronger access model -- it is a per-application, least-privilege transport (the model NIST calls Zero Trust Network Access), whereas a traditional VPN is a perimeter model that places the remote workstation onto the private network.
For what SBN Tunnel is, how to configure it, and troubleshooting, see the SBN Tunnel page.
Why does Innovative247 offer the SBN Tunnel?
SBN Tunnel exists to solve two problems a VPN handles badly for a 24/7 monitoring operation.
- Reach, without exposure. SBN operator workstations — and Concentrator / BackupHostImport, increasingly cloud- and remote-hosted — need to reach SBN Cloud infrastructure on a protected private network. A VPN drops the whole workstation onto that network (broad access, a managed client, a standing inbound hole). The tunnel gives exactly the reachability needed and nothing else: a narrow, application-scoped, centrally-licensed, instantly-revocable SSH path to only the named endpoints.
- Availability we control. Innovative delivers a 24/7 support service. VPN links have not proven a reliable enough transport — when a customer's VPN appliance or ISP drops, our support degrades and we have no lever to pull. SBN Tunnel is a multi-active server farm: every member presents the same identity, so clients fail over between members automatically and transparently, with no reconnect prompt and no re-trust. The client's contract is to always reconnect — it drains and re-establishes across the farm rather than giving up. Innovative owns this path end to end, which means we can observe it, drain a member for a zero-downtime upgrade, revoke access farm-wide in one action, and guarantee reachability rather than inheriting whatever reliability a third-party VPN happens to provide.
SBN Tunnel is additive — VPN and direct connections still work; a workstation uses the tunnel only when a license key is configured.
Architecture
The workstation never receives an address on the private network. It cannot route, scan, or reach anything except the endpoints its license names -- nothing else on the network is reachable through the tunnel.
Connection flow:
- The workstation makes a single outbound TCP connection to the tunnel farm. No inbound firewall rules are required on the customer side, and no VPN client or virtual network adapter is installed.
- Before any credential is sent, the client cryptographically verifies the server's identity (see the layers below). If verification fails, the client refuses to connect -- it does not fall back.
- The client presents its license and is issued a limited-lifetime connection certificate. The license credential itself is encrypted before it leaves the workstation and never crosses the wire in clear text.
- The server authorizes the request against the license's endpoint allow-list and, if permitted, forwards traffic to exactly one declared destination (host:port). The forwarded connection is exposed to the local driver on the workstation's loopback interface only.
- The endpoint (e.g., data server) login and the application login still apply on top -- the tunnel adds authentication layers, it does not replace any.
Every connection passes six gates in sequence, and each one fails closed:
Defense in Depth -- the Security Layers
# | Layer | Control |
|---|---|---|
1 | Transport encryption | SSH-2 negotiating exclusively from a modern cipher set -- AES-GCM, ChaCha20-Poly1305, and AES-CTR with SHA-2 integrity; the same cipher families used by IPsec and TLS 1.3. Legacy weak algorithms (RC4, 3DES, CBC modes, MD5) are not offered. All traffic, including the SQL session, is encrypted between workstation and tunnel server. |
2 | Server identity (anti-impersonation) | The client pins the tunnel server's public key fingerprint, and that fingerprint is additionally signed with an ECDSA P-256 key whose public half is delivered out-of-band inside the customer's license. An attacker on the network path cannot impersonate the tunnel server: they cannot produce a valid signature, and replaying the genuine one only pins the genuine server. Verification is fail-closed -- no valid signature, no connection. |
3 | Credential confidentiality | The license credential is encrypted (RSA-OAEP / SHA-256) to the verified server key before it leaves the workstation. A passive eavesdropper on any network segment cannot capture a usable credential. Current (v3) license keys have no plaintext fallback; older v2 keys send the license in the clear and should be reissued as v3. |
4 | Client authentication | Connections are authenticated with limited-lifetime certificates issued per workstation against a valid, active license -- never a static password. Certificates are individually revocable, and suspending a license takes effect across the entire farm immediately and drops its live sessions -- central, instant revocation. |
5 | Per-endpoint authorization (least privilege) | Every license carries an explicit allow-list of named endpoints. The server enforces it on every connection request, in both directions. An endpoint not declared by the operator is unreachable by any license. Every denial is recorded in the audit log. |
6 | Network-level controls | The farm additionally enforces IP allow/reject lists (single address or CIDR), country/continent allow-listing, and automatic rate-limiting with temporary blocking of addresses generating authentication failures. |
7 | Independent data-tier authentication | The tunnel terminates at a TCP forward, not at the data. Reaching the database still requires the SQL server login, and using the application still requires the SBN user login. Three independent credentials -- a stolen license key alone reads nothing. |
8 | Audit trail | Connects, disconnects, certificate issuance, authorization denials, and administrative actions are logged across the farm and reviewable per event. |
SBN Tunnel vs. Traditional VPN
The fundamental difference is what a connected workstation can reach. A VPN places the workstation on the private network; SBN Tunnel never does:
Property | Traditional VPN (IPsec / SSL-VPN) | SBN Tunnel |
|---|---|---|
Encryption in transit | AES-GCM / ChaCha20 suites | Equivalent -- SSH-2 with AES-GCM / ChaCha20-Poly1305 / AES-CTR + SHA-2 |
What the remote machine can reach | A network. The workstation gets a routable address on the private network (or routed subnets) and can attempt connections to anything on it -- every host, every port, is exposed to lateral movement if the workstation is compromised. | Named endpoints only. The workstation never joins the private network. It can reach exactly the database endpoints its license names -- nothing else exists from its point of view. A compromised workstation's blast radius is one TCP port per declared endpoint, each still guarded by SQL and application logins. |
Granularity of access control | Typically per-user or per-group at the network/subnet level; per-host/per-port rules require separate firewall engineering and drift over time. | Per-license, per-named-endpoint, enforced in the connection path itself and audited on every denial. The access policy is the configuration -- there is no separate firewall layer to drift out of sync. |
Revocation | Disable the account/cert; established sessions often survive until rekey or timeout; revocation-list handling varies by vendor. | Suspend the license: propagates to every farm member immediately and drops live sessions. |
Server impersonation / man-in-the-middle | Depends on correct PKI deployment; widely-documented real-world weaknesses (accepted self-signed gateway certs, user-clickable warnings). | Pinned server key plus an out-of-band cryptographic attestation carried in the license. Fail-closed, with no user-clickable override and no expiring certificate that can lapse into a warning-fatigue state. |
Credential exposure on the wire | Varies; password-based VPN logins have been a recurring breach vector. | License credential is asymmetrically encrypted before transmission; never sent in clear. |
Attack surface exposed to the internet | VPN concentrators expose a large protocol stack (IKE, ESP, TLS portal, web UI). VPN gateways have been among the most-exploited internet-facing devices in recent years -- CISA's Known Exploited Vulnerabilities catalog lists actively exploited CVEs across the major VPN vendors, and CISA/NSA have issued joint guidance specifically on hardening VPN gateways. | A single TCP port speaking SSH-2 -- one of the most heavily audited protocols in existence, with no web portal, no IKE stack, and no user-facing login page to phish. Management and dashboard interfaces are internal-only. |
Client software on the workstation | VPN client install, virtual adapter, route table changes, admin rights, version management. | No VPN client, no network adapter, no route changes. The tunnel component ships with SBN and touches only a loopback port. |
Coexistence | Competing VPN clients and split-tunnel policies conflict. | Runs alongside any existing VPN without conflict; purely additive. |
Availability | The concentrator is commonly a single point of failure; failover is an HA appliance pair at extra cost. | Multi-active server farm; clients fail over between members automatically in seconds, and members can be drained for zero-downtime maintenance. |
Auditability of data-path access | NetFlow/firewall logs, correlated after the fact. | First-class audit events in the access path: every session, certificate, and denial, attributable to a license. |
The Architectural Point
A VPN answers the question "is this machine allowed onto the network?" -- and once the answer is yes, the network's interior is exposed to that machine. SBN Tunnel answers "is this license allowed to reach this specific database endpoint?" -- per connection, every time, with the answer enforced and logged in the data path itself.
This is the access model that NIST SP 800-207 (Zero Trust Architecture) recommends and that CISA's Zero Trust Maturity Model describes as the successor to perimeter VPN access: deny by default, authenticate and authorize each session to each specific resource, and grant least-privilege access to the application rather than the network. SBN Tunnel implements that model natively. A traditional VPN can only approximate it with additional firewall segmentation that must be built and maintained separately.
Frequently Asked Security Questions
Is the encryption weaker than our VPN's?
No. The tunnel uses SSH-2 negotiating from a modern-only cipher set -- AES-GCM, ChaCha20-Poly1305, and AES-CTR with SHA-2 integrity -- the same cipher families specified for IPsec and TLS 1.3, with legacy weak algorithms excluded entirely. Encryption strength is equivalent; the differences between the two architectures are in access scope, authentication layering, and attack surface, where the tunnel's model is stronger.
What happens if a license key is stolen?
Three independent things stand between the thief and data: the license only grants a transport to its named endpoints; the database rejects them without a valid SQL login; the application rejects them without a valid SBN user login. Meanwhile the license can be suspended centrally, which immediately drops any live session it has, and the attempt trail is in the audit log.
Can someone on the network path (hotel Wi-Fi, compromised router, hostile ISP) intercept the session?
No. The client verifies the server's identity against a signature anchored in the license itself -- which the attacker cannot forge -- before sending anything sensitive, and refuses to connect if verification fails. Session traffic is then encrypted with authenticated ciphers. A man-in-the-middle can block the connection (denial of service), but cannot read, alter, or impersonate it.
Can the tunnel be used to reach other systems on the hosting network?
No. The tunnel is not a network bridge. Only endpoints explicitly declared by the operator exist, and each license is restricted to its own allow-list. Connection attempts to anything else are rejected and audited. Contrast: a routed VPN client can, by design, attempt connections to any address in the routed scope.
What does the customer firewall need to allow?
Outbound only: HTTPS to the dashboard port, and TCP to each tunnel server's SSH port. The SSH port carries both HTTP (server verification and connection-certificate issue) and SSH (the encrypted session), so the rule must allow all TCP traffic on it; a rule that permits only the SSH application blocks the connection. No inbound rules, no protocol exceptions for IKE/ESP, no GRE.
Which TLS versions are used?
TLS 1.2 and TLS 1.3. TLS 1.0 and TLS 1.1 are refused. TLS protects activation and license checks against the dashboard. Connection certificates are issued and renewed over HTTP on the tunnel server's port; the license key in that request is encrypted (RSA-OAEP / SHA-256) to the server key, which is verified against the signature carried in the license. The database session itself travels inside the SSH-2 channel.
What happens if a tunnel server fails?
The farm is multi-active. Clients detect the drop in seconds and automatically reconnect to a surviving member, re-verifying its identity through the same pinning-plus-attestation checks. Planned maintenance uses a drain mode that migrates sessions to healthy members with no downtime.
Standards Referenced
- SSH-2 protocol: RFC 4251-4254 (architecture, authentication, transport, connection)
- TLS 1.2 / TLS 1.3: RFC 5246 / RFC 8446 (dashboard activation and license checks; TLS 1.0 and 1.1 refused)
- AES-GCM: NIST SP 800-38D; ChaCha20-Poly1305: RFC 8439
- ECDSA P-256: FIPS 186-5 / NIST SP 800-186 (server-identity attestation)
- RSA-OAEP: RFC 8017 / PKCS #1 v2.2 (credential confidentiality)
- NIST SP 800-207, Zero Trust Architecture -- per-resource, per-session least-privilege access as the recommended successor to perimeter access
- CISA Zero Trust Maturity Model -- application-level access in place of network-level access
- NSA/CISA joint guidance, "Selecting and Hardening Remote Access VPN Solutions" (2021) -- documents the exploitation pressure on traditional VPN gateways that application-scoped access avoids
- NIST SP 800-77 Rev. 1, Guide to IPsec VPNs -- the baseline traditional-VPN control set this page compares against