Application tunnels
[!NOTE] Application tunnels need a valid license. An application tunnel connects NullWard to applications in another network, such as an office, a private cloud or a Kubernetes cluster, without opening any inbound ports there. How it works A small program, the connector, runs in the same network as your applications. It makes an outbound WireGuard connection to NullWard on UDP 7055. Nothing in your network needs to accept inbound connections. Visitors reach your service's public hostname on NullWard. NullWard applies the WAF, authentication and every other check first. Allowed requests go through the tunnel to the connector, which forwards them to the application and returns the response. A connector serves one or more upstream groups: named sets of backend addresses, such as Web App or API Server. The connector reports its groups to NullWard, and each NullWard service picks the tunnel and group to send its traffic to. One tunnel can serve many services. There are three ways to run a connector: Connector Runs as Configured with Linux host A systemd service A YAML file Docker A container The same YAML file, mounted into the container Kubernetes An operator installed with Helm Labels and annotations on your Kubernetes Services The first two use a Generic connector tunnel. Kubernetes uses a Kubernetes operator tunnel. 1. Prepare NullWard (once) Open UDP 7055 to NullWard from wherever your connectors run, and publish it in Docker Compose: "7055:7055/udp". Settings > Tunnels > Public Endpoint: set the address connectors dial, for example waf.example.com:7055. Connector configuration files include it, so set it before you download any. For the one-command install: connector hosts also need to reach NullWard's public HTTP port (80). It's normally open already, for HTTPS redirects and certificate validation. 2. Create the tunnel Go to Services > Tunnels and click Create Tunnel. Enter a Name, then choose the Connector type. You can't change the type later. Generic connector: for a Linux host or Docker. Kubernetes operator: for a Kubernetes cluster. The new tunnel appears in the list as Disconnected until its connector dials in. Each row has buttons to edit the tunnel, show its setup instructions (the info icon), download its configuration, and delete it. [!WARNING] The downloaded configuration (tunnel-<name>.yaml, or tunnel-<name>-values.yaml for Kubernetes) contains the tunnel's private WireGuard key. Keep it secret, store it with restrictive permissions, and don't commit it to source control. Anyone who has it can impersonate the connector. The connector configuration file (generic connectors) Download the file with the tunnel's download button. Most of it is filled in for you: Edit upstreams to describe your applications. The default localhost:8080 is only a placeholder. name: the group name you'll choose on the NullWard service. protocol: http, https, or h3 (HTTP/3 to the backend, see HTTP/3). tls_skip_verify: skip certificate checks for https and h3 backends. Use it only on trusted internal networks. targets: one or more host:port addresses. The connector load-balances across healthy targets. If you add NullWard nodes to a cluster later, re-download the file to pick up the new waf_peers. Up-to-date connectors also learn about new nodes automatically; the tunnels list shows peer discovery ready for those. Run the connector on a Linux host (systemd) There are two ways to install the connector on a Linux or macOS host: one command, or a manual install. Option A: install with one command The one-command install runs on the connector host and needs only outbound access to NullWard's public HTTP port (80) and the tunnel port (UDP 7055). It never contacts the management interface, and nothing secret travels over the network: the installer and the connector program are checked against SHA-256 hashes shown in your dashboard; the tunnel's WireGuard private key is created on the connector host and never leaves it. Only the public key is…
NullWard documentation