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: trueterminates client TLS at the L4 listener using the global TLS SNI certificate store. The backend then receives plaintext.backend_tlsmakes OMLB initiate verified TLS to the backend. It is an object, not a boolean;server_nameis required for SNI and hostname verification. Withoutca_file, system trust roots are used.client_certandclient_keyare 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.