ProxyPass vs. port forwarding
Reaching a device shouldn't mean opening a door to the internet.
Port forwarding plus dynamic DNS is the classic hack to reach a box behind a router. It also puts a service directly on the public internet — and quietly stops working the moment the customer is behind CGNAT.
Short answer: Port forwarding needs router access, a routable public IP, and an open inbound port that anyone can scan. ProxyPass needs none of that: the node connects outbound, so there's no port to open, it works behind CGNAT and LTE, and nothing is exposed to the public internet.
The honest comparison
| ProxyPass | Port forwarding + DDNS | |
|---|---|---|
| Open inbound port | None | Required — publicly reachable |
| Router / firewall access | Not needed | Required on the customer router |
| Works behind CGNAT / LTE | Yes | No (no routable inbound) |
| Public IP / static IP | Not needed | Needed, or fragile DDNS |
| Attack surface | Outbound only, nothing to scan | An exposed service on the internet |
| Reaches more than one device | Whole LAN behind the node | One port to one service |
Where port forwarding still makes sense
For a single device on a connection you control, with a static IP and a router you own, a forwarded port is simple and free. Plenty of home-lab setups live happily this way.
It falls apart at fleet scale and in networks you don't own: you can't reconfigure a customer's router, you can't rely on them having a public IP, and every open port is one more thing their security team has to justify.
How ProxyPass does it instead
The node dials out to ProxyPass over TLS and keeps the connection open. Your requests ride back down that existing outbound connection — so the customer network stays completely closed, with no listener and no inbound rule. Behind CGNAT, on an LTE router, on a guest VLAN: it just works, because nothing needs to reach in.
See it on your own devices
Start a pilot — the typical first invoice is €0. We'll send your install script within 24 hours.