# L4 Tunnel

> Hide a backend behind a GRE tunnel — through shared platform L4 edge nodes, or between two of your own fleet servers — with the real client IP preserved.
>
> Canonical: https://xdp.network/docs/products/l4-tunnel · Updated 2026-08-17

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. The product page offers two modes on a toggle:
**Tunnel With Us** (TWU), which fronts you through a shared platform edge node, and
**Bring Your Own Servers** (BYOS), which pairs two servers you own.

## Tunnel With Us (shared edge nodes)

TWU puts a platform-operated L4 edge node in front of one of your fleet servers.
Choose **New tunnel** and the wizard walks through:

1. **Name** — a short label; it names the tunnel interface on both ends.
2. **Node** — pick an edge node, or leave placement automatic (a random eligible
   node with capacity). The step is skipped when no node is user-selectable.
3. **Ports** — what the node forwards to you. On a **full-IP** node you get the whole
   node address 1:1 (every TCP and UDP port, 1–65535; one live tunnel per node). On
   a **port-range** node the free-ports picker shows the first ten free ports inside
   the node's window with a tcp/udp/both toggle, search and load-more; you can also
   type explicit ranges. A tunnel allows up to 32 port entries (2048 expanded ports)
   that don't overlap another tenant on the node.
4. **Destination** — one of your online fleet servers. The daemon installs the
   `gretund` agent on it automatically when missing.
5. **Rate limits** — node-side caps, see below.
6. **Return mode** — tunnel return or DSR, see below.
7. **Review** — create, then watch live progress as both ends install and configure.

## Bring Your Own Servers

BYOS pairs two of your own fleet servers: a public **origin** (the front that takes
the traffic) and a hidden **destination** (the backend that does the work). Both need
the fleet daemon; `gretund` installs on both with one click when you create the
tunnel, then the platform pushes the config to each side. The wizard asks for the
origin, the destination (must be a different server), ports, return mode and
origin-side rate limits.

## Rate limits

Both modes share the same editor, with 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.

## The tunnel detail page

Click a tunnel to open its detail page. Three tabs:

- **Overview** — status with actions (push the config again, delete), a per-end card
  for each side (online state, gretund state, last install/config job), the forwarded
  ports, rate-limit chips, the return mode, and a 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). A **Bandwidth** card below charts hourly byte totals over 48h, 7
  or 30 days.
- **Control** — edit the rate limits and return mode; saving re-pushes the config to
  both ends. Ports are read-only — delete and recreate the tunnel to change them.

## Deleting a tunnel

Delete offers two modes:

- **Graceful** (default) — queues teardown jobs on both ends; each daemon removes
  the tunnel device, routes and rules on its next heartbeat. The row disappears
  immediately.
- **Force delete** — removes the row and its metrics right now with no teardown. Use
  it when an end is offline or the tunnel is stuck; stale config may linger on the
  boxes.

## Next steps

- [L7 Shield](/docs/products/l7-shield)
- [Cloudflare connections, Analytics and Auto Setup](/docs/products/cloudflare)
- [Health Monitor](/docs/servers/health-monitor)