Traffic

L4 TCP streams

L4 entries forward a byte stream to one backend address. They are independent of HTTP listeners, routes, upstream pools, HTTP health checks, and HTTP plugins.

Configure a stream

l4:
  # Plain TCP passthrough to a plaintext backend.
  - name: postgres
    address: "0.0.0.0:5432"
    backend: "10.0.0.40:5432"
    timeout: 5m
    ipv6: true

  # Terminate client TLS using the global SNI store, then send plaintext.
  - name: mqtt-tls
    address: "0.0.0.0:8883"
    backend: "10.0.0.50:1883"
    tls: true

  # Connect to the backend with verified TLS and optional client credentials.
  - name: redis-upstream-tls
    address: "127.0.0.1:6380"
    backend: "redis.internal:6380"
    backend_tls:
      server_name: redis.internal
      ca_file: /etc/ssl/certs/internal-ca.pem
      client_cert: /run/secrets/redis-client.pem
      client_key: /run/secrets/redis-client-key.pem
    timeout: 60s

Every L4 entry needs a unique name, a literal address, and one backend in host:port form. The idle/connect timeout defaults to five minutes. Set ipv6: true only with an IPv4 wildcard address to bind the matching v6-only wildcard socket as well.

TLS direction matters

  • tls: true terminates client TLS at the L4 listener using the global TLS SNI certificate store. The backend then receives plaintext.
  • backend_tls makes OMLB initiate verified TLS to the backend. It is an object, not a boolean; server_name is required for SNI and hostname verification. Without ca_file, system trust roots are used.
  • client_cert and client_key are optional backend mTLS credentials but must be supplied together.

Operational limits

An L4 entry is a single TCP forwarder, not a load-balanced L4 pool. It does not participate in HTTP routing, HTTP request retries, HTTP access logs, or route caching. Validate file paths and addresses with omlb --check, then perform a protocol-level connection test from the intended client network.