RTFM · Networking

Direct public host, NAT, or HAProxy?

There is no universal 'right' way to publish Saphira. Choose the path that makes ownership, TLS, logs, routing, and failure recovery clearest for your location.

The three normal arrangements

Public-service deployment choices
Arrangement	Traffic path	Best fit
Direct public host	Internet → provider/router firewall → Saphira service	A VPS, datacentre host, or a small dedicated server with its own public address.
NAT or port-forwarded host	Internet → consumer/business router → Saphira service	A home or office where the router owns public IPv4.
HAProxy edge	Internet → HAProxy → private MailDragon/webDragon backend	A business or multi-service design that needs one controlled public edge.

All three need a listening service, a host firewall, correct DNS, and a real external test. NAT changes where the public-to-private translation occurs. HAProxy changes which host accepts the client connection. Neither removes the need for firewall policy or a return route.

Same service, different edge

Direct public
Internet → 203.0.113.10 Saphira → nftables → webDragon

NAT
Internet → 203.0.113.25 router → 192.168.1.50 Saphira → nftables → webDragon

HAProxy edge
Internet → 203.0.113.10 HAProxy → 192.0.2.30 webDragon
                                  └→ 192.0.2.25 MailDragon

Decide where TLS ends

TLS termination means the machine that accepts the encrypted connection has the certificate and decrypts the traffic. For webDragon, HAProxy can terminate HTTPS and pass ordinary HTTP to a private backend, or it can pass encrypted TCP through so webDragon owns TLS. For MailDragon, TCP pass-through is normally easiest to reason about because Postfix and Dovecot own their SMTP/IMAP TLS behaviour.

TLS ownership
Design	Certificate lives on	Backend sees
Direct webDragon	webDragon	The real client connection.
HAProxy HTTPS termination	HAProxy	HTTP plus trusted X-Forwarded-For/X-Forwarded-Proto headers.
HAProxy TCP pass-through	webDragon or MailDragon	The real TLS connection; proxy must not pretend to be HTTP.

Do not enable PROXY protocol or trust X-Forwarded-For on a backend by guesswork. A backend must be configured to understand the exact mechanism, and it must trust only the proxy address. Otherwise client-address logging and access control can become wrong or spoofable.

The outbound-mail address is a separate decision

Mail's public identity follows the address that actually sends SMTP to other mail systems. If a MailDragon backend sends directly from its own public address, that address needs the PTR. If outbound SMTP exits through a NAT gateway, that gateway's public address needs the PTR. HAProxy receiving inbound mail does not automatically become the outbound sender and cannot repair a bad outbound reverse DNS record.

Prove the whole path, not one machine

1. Identify the public address
Use the router/provider control plane and a controlled remote test. Record whether it is IPv4, IPv6, or both.
2. Inspect every listener
Run ss -lntup on the edge and backend. A proxy cannot reach a backend that is not listening at the selected private address and port.
3. Trace the policy
Check provider/router filtering, edge nftables, proxy configuration, backend nftables, and routes in that order.
4. Test from outside
Use a remote host or phone hotspot and inspect logs/counters on the expected hop. A browser on the LAN can hide a broken Internet path.