Manu
CV
← Projects

leVPN

A multi-region HTTP CONNECT proxy built in Go and provisioned on AWS with Terraform, hardened as an egress gateway: web ports only, no private or cloud-metadata destinations, and every destination checked after DNS resolution.

Status
Shipped
Started
Apr 2026
Stack
Go · Terraform · AWS EC2 · Route 53 · S3 · CloudFront · certbot · React
Code
Live traffic across regions: destination, bytes and duration per connection. Client addresses are blurred.
Live traffic across regions: destination, bytes and duration per connection. Client addresses are blurred.
Architecture: management plane (S3 portal and PAC files behind CloudFront) separated from the data plane (one Go proxy per region, :443 TLS and :8080 HTTP).
Architecture: management plane (S3 portal and PAC files behind CloudFront) separated from the data plane (one Go proxy per region, :443 TLS and :8080 HTTP).
Operations dashboard: two of four regions live, 11,892 connections, 6.9 GB inbound.
Operations dashboard: two of four regions live, 11,892 connections, 6.9 GB inbound.
The same forward-proxy pattern as a secure web gateway such as Zscaler ZIA, without the TLS inspection and policy layers.
The same forward-proxy pattern as a secure web gateway such as Zscaler ZIA, without the TLS inspection and policy layers.
Browser extension: one click per region, no client to install.
Browser extension: one click per region, no client to install.

Goal. Study enterprise egress filtering from the client side.

Implementation.

  • Core: HTTP CONNECT forward proxy in Go, with TLS on 443 and plain HTTP on 8080 for browsers configured through PAC files.
  • Hardening: web ports only, no private or cloud-metadata destinations; each destination is checked after DNS resolution and dialed by IP.
  • Infrastructure: reusable Terraform module, one boolean flag per region, on AWS (EC2, Route 53, S3, CloudFront).
  • Usage: 6.9+ GB over 11,800+ connections for 20+ users at $20/month.

Objective

Working in pre-sales connectivity involves designing gateways that inspect enterprise egress traffic (SASE and SSE). I built leVPN to inspect this traffic from the client perspective: understanding minimal tunnel mechanics on the wire and managing multi-region proxy infrastructure.

System overview

  1. Data plane: A Go service using net and net/http packages. It handles HTTP CONNECT methods, hijacks raw TCP connections, and forwards traffic bidirectionally using io.Copy. Unauthenticated requests receive immediate 407 Proxy Authentication Required responses.
  2. Multi-region infrastructure: Deployed on t3.micro instances across us-east-1, eu-west-1, ap-southeast-1, and sa-east-1. Each region is provisioned as an independent Terraform module instance enabled via boolean flags.
  3. Control plane: Web portal hosted on S3 and CloudFront, per-region PAC files, a /metrics endpoint on each proxy instance, and a React dashboard polling metrics every 5 seconds.

Production stats

6.9+ GB transferred across 11,800+ proxy sessions for 20+ active users at $20 monthly infrastructure cost.

Design choices

Dual port listeners (8080 and 443). Chromium browsers do not route traffic through HTTPS proxies specified in PAC files. Instead of requiring custom client software on end-user devices, port 8080 serves standard HTTP CONNECT for browsers via PAC, while port 443 provides TLS CONNECT for system utilities and curl.

Automated DNS before TLS provisioning. certbot HTTP-01 challenges require active DNS resolution, which depends on AWS Elastic IP allocation. Terraform uses sequenced null_resource provisioners with explicit depends_on dependencies tied to Route 53 records to execute provisioning in a single pipeline run.

In-process metrics collection. Built-in atomic counters and a 200-entry ring buffer replace external monitoring agents, reducing memory footprint on t3.micro nodes.

Out-of-band management traffic. When proxy PAC files were enabled on monitoring nodes, dashboard /metrics requests routed through the proxy itself, causing all regional dashboard cards to reflect the local proxy node. Observability traffic must remain strictly separated from the data plane it monitors.

Hardening (October 2026)

  1. No internal destinations. Each CONNECT target is resolved before dialing. If any returned address is loopback, private, link-local (which covers the EC2 metadata endpoint 169.254.169.254) or CGNAT, the request is refused with 403.
  2. Dial the checked IP, not the hostname. The proxy connects to the address it validated, so a second DNS answer cannot redirect the tunnel to an internal host (DNS rebinding).
  3. Web ports only. Destinations other than 80 and 443 are refused.
  4. HTTPS only. Plain-HTTP forward requests get a 405; the proxy only tunnels CONNECT.
  5. Credentials. /metrics requires the same credentials as the proxy, an empty configured password rejects every request, and the password check runs in constant time.

Known limits

  1. Port 8080 uses unencrypted Basic Auth. The browser proxy path sacrifices credential encryption for zero-install compatibility. On shared networks, authentication must be restricted to TLS listeners on port 443.
  2. Throughput and latency unbenchmarked. Performance under packet loss (tc netem) and CPU usage per tunnel have not been formally benchmarked. Comparative efficiency between HTTP CONNECT and WireGuard remains theoretical.
  3. Egress inspection bypass untested. Using valid TLS certificates on custom domains allows traffic to look like HTTPS, but does not guarantee evasion against deep packet inspection or active URL categorization engines.