An IoT gateway behind NAT without opening ports: frp over WebSocket on 443

The problem

The gateway sits in the customer's building: behind the ISP's router, often behind LTE carrier-grade NAT, on a network we don't manage. Port forwarding is out – it needs access to the router, and SSH exposed to the internet invites every bot. A site-to-site VPN means extra setup on the customer's side, and the installation is supposed to be plug and play.

Reverse the direction

The gateway connects outwards by itself – just like a browser. We use frp: frps runs on the server, frpc on the gateway. The client keeps a persistent connection and registers a tunnel: "port 20013 on the server → port 22 on me".

serverAddr = "gw.example.com"
serverPort = 443
transport.protocol = "wss"
auth.token = "…"            # from the server, never from the repo

[[proxies]]
name = "PB000000013-ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 20013

Why WebSocket on 443

Many corporate networks only allow HTTP(S). frp can tunnel traffic inside a WebSocket over TLS, so to the firewall it is an ordinary HTTPS connection to our domain. On the server, the reverse proxy (Caddy in our case) routes the WebSocket path to frps and everything else to the readings API. One domain, one port, one certificate.

Security

• Tunnel ports are not public. They only listen inside the server; you reach a gateway from the server, with the server's key: ssh gateway PB000000013.
• Secrets never touch the installer's laptop. The setup script uses a single SSH session, reads the frp token straight from the server and stores it on the gateway with mode 600.
• A fixed port derived from the gateway number (PB000000013 → 20013). A clash shows up immediately in the log: port already used.
• The same version of frpc and frps – fewer surprises after updates.

What we get

Remote service without a site visit, gateway app updates, diagnostics (journalctl -u frpc). All the customer has to provide is internet access.