Access edge devices behind NAT (without a VPN)
You can access edge devices behind NAT without a VPN by using a persistent outbound QUIC connection (HTTP/3 over UDP port 443, TLS 1.3). With m87 (make87's command line + device runtime), the device connects out to the make87 platform, and you can open interactive sessions and forward ports/sockets without exposing inbound ports or changing router/firewall rules.
The problem
Most edge devices live on networks you don't control — behind NAT with dynamic IPs, on mobile/LTE connections with CGNAT, or inside corporate networks with egress filtering and port restrictions.
Traditional inbound access (opening ports, managing SSH exposure, maintaining bastions) requires per-device port forwarding rules and a stable public IP. These assumptions break behind CGNAT where there's no port to forward, or when IPs rotate and firewall policies change.
Quick start (example)
1) Authenticate from your laptop
m87 login
2) Verify your device is reachable
m87 devices list
3) Open an interactive session
m87 <device> shell
Sessions are multiplexed over the device's persistent outbound connection — no inbound ports required.
What you can do once you have reachability
Forward a port (debug, UI, APIs)
m87 <device> forward 8080:localhost:8080
Deploy software (example: Docker Compose)
m87 <device> docker compose up -d
Port forwarding and command execution use the same underlying connection.
Alternatives (and tradeoffs)
VPN-based access
Pros:
- Full Layer 3 access to all hosts/ports on the private subnet
- Mature cryptographic protocols — WireGuard (Noise framework, ChaCha20-Poly1305), IPsec (IKEv2)
Cons:
- Requires key distribution and revocation infrastructure (PKI or PSK management)
- Each device needs static config or provisioning step to join the mesh
- Split-tunneling misconfiguration can leak DNS queries or break connectivity when VPN and local subnets overlap
- VPN client software required on operator machines
Inbound SSH
Pros:
- Native on most Linux devices; no additional daemon
- Direct TCP connection with well-understood security model
Cons:
- Requires publicly routable IP or port forwarding on the NAT gateway
- Unusable behind CGNAT — no port to forward
- Key management becomes manual at scale (authorized_keys distribution, rotation)
- Each exposed device is a target for port-22 scanners and brute-force attempts; requires fail2ban or rate-limiting
Bastion host (jump box)
Pros:
- Centralizes SSH access; devices only accept connections from bastion IP
- Single point for MFA enforcement and audit logging
Cons:
- Bastion itself needs inbound exposure (same CGNAT problem if bastion is also NATed)
- Requires provisioning, patching, and monitoring a persistent VM
- All traffic funnels through one host — latency overhead for interactive sessions; throughput ceiling for bulk transfers; single point of failure
- ProxyJump configuration required on all clients; complicates tooling expecting direct SSH
FAQ
Do I need to open inbound ports?
No. The device maintains a persistent outbound connection; sessions are multiplexed over this channel without inbound firewall rules.
Does this work on mobile/LTE or CGNAT networks?
Yes. Only outbound UDP port 443 (QUIC/TLS 1.3) is required — no listening ports or NAT port mappings.
Can I use my normal development workflow?
Yes. Once reachable, you can forward ports/sockets and use your local tools against localhost.
Do I have to run it as a daemon?
No. The m87 runtime can run in the foreground during development; production typically runs it as a service.
Is this just a bastion host?
No. A bastion is infrastructure you operate to reach private networks. With m87, devices connect outbound and sessions are relayed through the make87 service over the device's outbound connection — you don't manage access servers.
Will this support direct device-to-device connections (P2P)?
That's on the roadmap. Even with direct paths, NAT traversal requires STUN/TURN coordination and relay fallback for symmetric NAT or strict firewall environments. m87 handles this automatically.