L4 Tunnel

Hide a backend behind a GRE tunnel between two of your own fleet servers, with the real client IP preserved and per-source rate limits.

Last updated

On this page

L4 Tunnel hides a backend server behind a GRE tunnel so attackers only ever see the front IP. GRE carries the traffic with the real client IP untouched. No proxy protocol, no header rewriting. You pair two servers you own: a public origin (the front that takes the traffic) and a hidden destination (the backend that does the work).

Create a tunnel

Both servers need the fleet daemon; gretund installs on both automatically when you create the tunnel, then the platform pushes the config to each side. Choose New tunnel on the product page and fill in:

  1. Name: a short label; it names the tunnel interface on both ends.
  2. Origin (public front) and destination (hidden backend): two of your online fleet servers. They must be different servers.
  3. Ports to protect: the All ports (1) toggle tunnels every TCP and UDP port (1 to 65535; SSH is auto-bypassed so you can't lock yourself out), or add explicit tcp/udp ports and ranges.
  4. Return mode: tunnel return or DSR, see below.
  5. Rate limits: origin-side caps, see below.

Create the tunnel and expand its row to watch both ends install and configure live.

Rate limits

The editor offers presets to start from:

  • High-traffic safe: per-source 100 conn/s and 2,000 pps (with bursts), a tunnel-wide 100,000 pps ceiling, and SSH bypassed. Real traffic, including SFTP, is untouched.
  • Strict: the safe preset plus a tunnel-wide 2,000 conn/s cap and a 900 Mbps bandwidth cap.
  • Custom: edit every field yourself.
  • Off: no rate limiting.

Per-source limits meter each visitor IP individually, so one flooding source can't consume the tunnel-wide budget. Bypass ports (for example tcp:22) are never rate-limited. Use them for SSH and management access so you can't lock yourself out.

Return mode

  • Tunnel return (default): replies flow back through the front end. Works everywhere.
  • DSR (direct server return): the destination replies straight to the client, so return traffic never touches the front. It requires the destination's provider to forward packets with a spoofed source IP; AWS, GCP, Azure and DigitalOcean filter these, and gretund falls back to tunnel return when it detects a filtering provider.

Read a tunnel

Click a tunnel row on the product page to expand its detail inline:

  • Status and actions: the current status, Push config (re-pushes the spec to both agents; available once gretund reports on both servers) and Delete.
  • Per-side cards: each end's online state, gretund state and last jobs.
  • Rate limits chips and a status timeline built from the job results.
  • Analytics: throughput (rx/tx bits per second), packets and drops per minute over 1h, 24h or 48h, from per-minute rollups the agents piggyback on heartbeats (48h retention).

Ports, rate limits and the return mode are fixed at creation. Delete and recreate the tunnel to change them.

Deleting a tunnel

Delete asks for one confirmation, then queues teardown jobs on both ends: each daemon tells its local gretund to remove the tunnel device, routes and rules on its next heartbeat. The row disappears immediately.

Retired shared-edge tunnels keep their own detail page (linked from the Connector page's services list while they exist), where delete offers graceful (queued teardown) and force (row and metrics removed at once, no teardown) modes.

Next steps