Why VPN Is Giving Way to SDP: A Deep Dive into Zero‑Trust Architecture

Preface

As the Spring Festival approaches, we reflect on a year of hard work and look forward to the next. During the pandemic, we experienced separation and longing, yet technology has brought us closer.

Beyond VPN

Prepare your VPN and ensure you can connect to the corporate intranet. However, VPNs are cumbersome and often slow, especially during urgent tasks.

Now, a new option—"Baohe" SDP—joins VPN to provide stronger online work support.

Why SDP?

With Baohe, many problems gain new solutions. When an urgent task arises during holidays, users no longer need to log into VPN, retrieve dynamic codes from Baohe, and repeat the process for each web application.

SDP offers faster access, comprehensive user activity tracking, and finer‑grained authentication, making the network more secure.

Future of VPN

VPN creates a virtual network adapter that captures all traffic, providing global proxy capabilities. It encrypts traffic, but because it operates at layers 2‑3, it cannot enforce fine‑grained permissions, leading to security risks if credentials are compromised.

Software‑Defined Perimeter (SDP) introduces zero‑trust principles, performing multi‑point verification and policy‑based access control, making it a better fit for modern security needs.

Implementation

Baohe acts as the SDP client and a forward proxy. Traffic from the OS is sent to Baohe’s built‑in proxy module, which repackages it and forwards it to the ZFE (Zero‑Trust Gateway) service.

ZFE integrates many features and can act as both an SDP proxy service and a zero‑trust gateway, providing full‑stack traffic control, real‑time request blocking, and user behavior analysis.

Forwarding Traffic to Baohe

We use the SOCKS5 protocol to forward traffic from the OS to Baohe. SOCKS5 supports optional authentication and can be configured via system APIs or PAC files.

[DllImport("wininet.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool InternetSetOption(IntPtr hInternet, int dwOption, IntPtr lpBuffer, int dwBufferLength);

[DllImport("wininet.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool InternetQueryOption(IntPtr hInternet, uint dwOption, IntPtr lpBuffer, ref int lpdwBufferLength);

On Windows, only PAC mode uses SOCKS5; global proxy defaults to SOCKS4.

For Chrome/Electron, proxy can be set via command‑line arguments:

--proxy-server="socks5://myproxy:8080"
--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"
--proxy-pac-url="http://localhost:8080/pac"

On Linux/macOS, environment variables configure the proxy:

export https_proxy="socks5://myproxy:8080"
export http_proxy="socks5://myproxy:8080"

SOCKS5 does not force applications to use the proxy; support depends on the application.

From Baohe to Cloud Proxy Service

Communication between Baohe and the proxy service uses a custom protocol named ARCHER, which encapsulates SOCKS5 and authentication data, then applies two‑stage encryption (header encryption and payload encryption).

ARCHER request fields include Version, Nmethod, Reserved, Methods, Ntoken, and Token. The response includes Version, Nmethods, Reserved, Methods, and Command (0 = success, 1 = auth failure, etc.).

Only the OS‑to‑Baohe segment must use SOCKS5; the Baohe‑to‑server segment can use any format as long as it meets security requirements.

Two‑Stage Encryption

The first stage encrypts the protocol header to obfuscate traffic. The second stage encrypts the SOCKS5 payload using an AEAD algorithm; we default to CHACHA20‑POLY1305 for its performance and security.

AEAD combines a stream cipher (CHACHA20) with a MAC (POLY1305) to provide authenticated encryption.

From Proxy Service to Target Service

Only the traffic between Baohe and the proxy service is encrypted; traffic from the proxy service to the target service remains raw, allowing visibility of HTTP requests when captured.

ZFE’s rule engine can perform fine‑grained access control based on user, device, and request attributes, which pure proxy services cannot achieve.

SDP Perspective

SDP enforces a "deny‑all" default, authenticates devices before establishing connections, and uses dynamic firewalls to mitigate DDoS attacks. It hides internal services from unauthorized devices, reducing attack surface.

The architecture integrates IAM for identity verification and ZFE for enforcement, creating encrypted tunnels only for trusted users.

Conclusion

While SDP cannot proxy every type of traffic (e.g., some VPN scenarios remain useful), for most B/S web workloads it satisfies the requirements.

Building such infrastructure demands patience and perseverance, but the resulting secure, zero‑trust network delivers lasting benefits.