Secure port forwarding without exposing services
Port forwarding gets services reachable — and accidentally everyone else. Here are patterns for controlled forwarding that do not turn firewalls into rubber stamps.
“Just open the port” is the shortest path to an incident. Port forwarding solves a real problem — getting a service reachable across a network boundary — but most setups widen the trust boundary far more than they need to. Here are patterns for controlled forwarding that don’t hollow out your firewall.
The three questions before you forward
- Who actually needs to reach this service? Usually: one engineer, one team, or one internal system. Rarely: the internet.
- For how long? A debugging session is minutes. A staging endpoint is weeks.
- What’s the blast radius if it leaks? A read-only metrics endpoint and a write-capable admin panel have very different risk profiles.
If you can’t answer these, don’t forward.
Pattern 1: reverse outbound tunnels
Instead of opening an inbound port on the target, run an outbound tunnel from the target to a relay. The operator connects to the relay, which forwards into the tunnel. This is how LynxTrac’s agent works, and it’s also what ssh -R, Cloudflare Tunnel, and ngrok do.
Advantages:
- No inbound ports on the target
- Works across NAT and strict egress policies
- Per-session credentials
- Can be killed remotely
Disadvantages:
- Depends on the relay being available
- Relay metadata is a new audit target
Pattern 2: scoped SSH tunnels
ssh -L is the classic “just forward it.” It works — and it’s narrowly scoped to a single user session, so it beats opening a firewall rule.
Guardrails:
- Only bind to localhost:
ssh -L 127.0.0.1:5432:db.internal:5432 bastion - Never bind to 0.0.0.0 by accident — that’s how forwarded ports end up on the public internet
- Use SSH certs with short TTLs
- Log the tunnel open in your jumpbox audit trail
Pattern 3: time-bounded firewall rules
If you genuinely need an inbound rule, make it auto-expire. Cloud firewalls support tagged rules; write them with a TTL tag and a scheduled job that removes them after 4 hours. Your ops team will thank you in six months when nobody can explain why 0.0.0.0/0 → 443 is still in the rules file.
What not to do
Don’t open ports permanently “for convenience.” Don’t use public-IP bastions with password auth. Don’t put database ports on the internet and call them “protected by security groups” — they’re one misconfiguration away from the wrong subnet. And don’t trust any setup that has no audit log of who forwarded what, when.
Try it yourself
LynxTrac is free forever for 2 servers — no credit card, no sales call. Start in under 2 minutes →
Related posts
First 30 minutes of an IT incident: what great teams do
The first 30 minutes make or break MTTR. Here are the concrete moves high-performing teams make — and the anti-patterns we see everywhere else.
Using AWS KMS for secure SSH credential management
Storing SSH credentials safely is harder than it looks. Here is how AWS KMS fits into a modern SSH access flow — the good, the friction, and the pitfalls.
Incident response without VPN access: a practical guide
Your pager just went off and the VPN is down. Here is a practical runbook for getting to the affected system, gathering context, and fixing it without tunnels.