3 ms·

Interesting! How do you handle port conflicts? What ports for public exposure are available?

ritcgab 10mo ago
Curious about this as well.
klipitkas 10mo ago
On the VPS we use: - 80 (standard http) - 443 (standard https) - 22 (obv for standard ssh) - 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections) Client-Side: The -R 80:localhost:8080 Explained The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on. No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain. So What Ports Are "Available" to Users? Any port - because it doesn't matter! Users can specify any port in -R: ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works! The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port. Why Use 80 Convention? It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because: - Server extracts BindPort from the SSH request - Stores it in the tunnel struct - Sends it back in forwarded-tcpip channel payload - Client matches on this to forward to correct local port - The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.
- BinaryIgor 10mo ago
  Nicely done! Thanks for the detailed answer ;)

Curious about this as well.

On the VPS we use: - 80 (standard http) - 443 (standard https) - 22 (obv for standard ssh) - 9090 (metrics / internal so I can have an idea of the generic usage like reqs/s and active connections) Client-Side: The -R 80:localhost:8080 Explained The 80 in -R 80:localhost:8080 is not a real port on the server. It's a virtual bind port that tells the SSH client what port to "pretend" it's listening on. No port conflicts - The server doesn't actually bind to port 80 per tunnel. Each tunnel gets an internal listener on 127.0.0.1:random (ephemeral port). The 80 is just metadata passed in the SSH forwarded-tcpip channel. All public traffic comes through single port 443 (HTTPS), routed by subdomain. So What Ports Are "Available" to Users? Any port - because it doesn't matter! Users can specify any port in -R: ssh -t -R 80:localhost:3000 proxy.tunnl.gg # Works ssh -t -R 8080:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 3000:localhost:3000 proxy.tunnl.gg # Also works ssh -t -R 1:localhost:3000 proxy.tunnl.gg # Even this works! The number is just passed to the SSH client so it knows which forwarded-tcpip requests to accept. The actual routing is done by subdomain, not port. Why Use 80 Convention? It's just convention - many SSH clients expect port 80 for HTTP forwarding. But functionally, any number works because: - Server extracts BindPort from the SSH request - Stores it in the tunnel struct - Sends it back in forwarded-tcpip channel payload - Client matches on this to forward to correct local port - The "magic" is that all 1000 possible tunnels share the same public ports (22, 80, 443) and are differentiated by subdomain.

BinaryIgor 10mo ago
Nicely done! Thanks for the detailed answer ;)