Skip to content

Firewall & ports ​

What your network team needs to allow for a collector, and for the Kilasec Connect devices that use it. Everything not listed here stays on the device or the collector host and never crosses your network.

At a glance ​

FromToPortWhatNeeded when
Kilasec Connect devicescollectorTCP 443device hop (TLS) — preferredalways, for Connect devices
Kilasec Connect devicescollectorTCP 8443device hop (TLS) — same listeneronly if :443 isn't available on the collector (see below)
PAC / proxy-configured clientscollectorTCP 8080the inspecting proxyPAC or explicit-proxy deployments
PAC clientscollectorTCP 9443proxy.pac over HTTPSPAC deployments
collectorinternetTCP 443AI providers + kilasec.comalways
remote devicescollector's public endpointTCP 443 (or the port you chose)device hop over the internetonly for remote devices not on a VPN

Devices and collector on the same subnet / zone: nothing to open — that traffic never reaches a firewall policy. You only need rules where a zone boundary sits between them (for example, a user VLAN and a server VLAN).

Why 443

The device hop is TLS, so it rides the port every firewall already allows outbound. On a Palo Alto, a rule like users → any, App-ID ssl, service application-default already covers it — application-default for ssl means 443 only, which is exactly why a custom port such as 8443 gets silently dropped by that rule.

The device hop: one listener, two ports ​

Kilasec Connect never sends the plaintext proxy port anything: devices only use the TLS hop, and the console only advertises the ports that hop is actually answering on, 443 first, then 8443.

The collector container runs unprivileged (uid 10001, no capabilities), so it can't bind 443 itself. The host launcher adds a host-local NAT redirect 443 → 8443 at every start instead:

  • It matches only packets addressed to the collector host (addrtype LOCAL) — on a box that also routes, forwarded HTTPS is never touched.
  • It's skipped when another service already listens on :443 on that host (it would steal that service's traffic), when iptables isn't installed, or when you set KILASEC_DEVICE_443=0 in /etc/kilasec/collector.env. Devices then use :8443 — open that instead. The collector's health check shows why, as AFW-113.
  • Source IPs are preserved, so per-device attribution and source-IP rules keep working.
  • A firewall on the collector host itself (ufw, firewalld, a cloud image's default iptables) sees redirected packets arriving on 8443, so allow TCP 8443 inbound there, even though your network firewall only needs 443.
  • uninstall removes it.

docker-compose installs have no host launcher, so devices use :8443. To serve 443 there, add the same rule yourself:

bash
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -m addrtype --dst-type LOCAL \
  -m comment --comment kilasec-device-443 -j REDIRECT --to-ports 8443

Collectors installed before this change keep serving devices on :8443 until the launcher is updated: curl -fsSL https://kilasec.com/retrofit-pinning | sudo sh.

Ports never move ​

Unlike the device client's local port, the collector's ports are fixed: devices, PAC files and your firewall rules all name them, so a collector that quietly moved to another port would be unreachable. If another process already holds 8080, 8443 or 9443, the installer refuses to enroll and says which process. If the conflict appears later, the collector skips only that listener, stays online and flags it as AFW-112 — rather than restart-looping.

TLS decryption on your firewall ​

If your firewall decrypts TLS (Palo Alto SSL Forward Proxy, FortiGate deep inspection, Zscaler…), add no-decrypt exemptions for:

  1. Devices → collector (the device hop). Decrypting it re-signs the hop with your firewall's CA; Kilasec Connect pins the collector's certificate, so the hop fails and the device is blocked (fail-closed) instead of inspected.
  2. The collector's source IP → internet. Otherwise AI-provider traffic is decrypted twice and the collector sees your firewall's certificate instead of the provider's.

Devices that go direct (paused, out-of-scope, or fail-open) are unaffected if your firewall's CA is already in their system trust store (pushed by GPO / MDM) — the usual setup wherever decryption is on.

Not on the network at all ​

These ports exist only on the device's loopback (127.0.0.1) and need no firewall rule: the Kilasec Connect proxy (3128) and AI gateway (3129) — including the port they move to when another app holds those.

Documentation for kilasec — the AI Agent Firewall.